Add tokens for signed/unsigned 128bit integer values.

[redstar]

Add the tokens to the token list and adds them to the parser where needed.
Does not add a lexer for these values - they are unused.

See ldc-developers/ldc#891 for the use case.

[yebblies]

Do you know if we can just have a single token type for integer literals? Or possibly just a signed and an unsigned?

[yebblies]

What's the plan for parser support and the rest of frontend integration? Something like complex_t?

[redstar]

Depending on the value of the literal and the postfix flags (U, L) the lexer decides about the token type. The parser uses this information to choose the type passed to IntegerExp. I fear that it is not easy to get rid of the multiple tokens.

[yebblies]

Oh yeah, I forgot about the postfixes. I guess it could be done like string literals, with flags for those things.

[yebblies]

Auto-merge toggled on

[redstar]

My plan is to integrate the support in the frontend. My ldc pull mostly changes frontend code.
I have no plans for the dmd backend...

[yebblies]

Yes, I'm only asking about the frontend. ctfe will need 128-bit integer support, like complex_t is currently used (and longdouble).

[ibuclaw]

I'd wait until ddmd to land first before 128bit CTFE support. Better to leverage std.bigint rather than invent a new synthetic type for N-bit integer support.

[yebblies]

Heh we'll see. 128-bit ints are a lot simpler than full bigint, and the complications using phobos brings.

[redstar]

I currently take advantage of GCC's __int128 but this is no general solution.

[ibuclaw]

@yebblies, you have two choices really.

1. Have a struct doubleInt { ulong, ulong } type with all necessary overload operators to interact with normal integers (the type itself just encodes the low and high parts of 128bit types).
2. Use bigint and get the same thing but with N-bit precision.

The same should really be done with real/double/float also. (OT, but I found that when talking to developers, they care more about consistent results in CTFE, not accurate when it comes to floating point).

[yebblies]

Choice 1 sounds sufficient and preferable!

One of the big annoyances is going to be that D doesn't have implicit struct construction, so there are 1000s of places in the frontend that will need an explicit constructor call.

[ibuclaw]

We do the same with ldouble(0) - it's expected. :)

[yebblies]

I know, it's just annoying. :(

[ibuclaw]

Choice 1 sounds sufficient and preferable!

Maybe we should start writing one and see? I've started one, now fill in the gaps. ;)

http://dpaste.dzfl.pl/909ccfd0de17

[yebblies]

http://dpaste.dzfl.pl/6c2207f074fb

[ibuclaw]

It's a bit incomplete, no?