Parsing numbers

[lerno]

Currently we're using C style number parsing. If we add a new lexer then possible to tweak that a little.

My idea would be:

1. Allow underscore: 0x3333_4322_ABCD, 100_000_000 etc
2. Support dec, hex, oct, bin
3. Support hex and dec floating points, e.g. 10.0e-2, 0x23A.A2p+2
4. Use o and b for bin and oct, so 0o12231, 0b102012120211

[lerno]

Furthermore, we should consider whether summing literals should be made with numeric towers before being rendered (int/float-folding could be done before C emit).

If we take a page from Zig, then:

1. Use max available int/float size to calculate literals.
2. Coerce to right size (here we should error if the int size now exceed max/min limits.
3. Explicit casting, e.g. cast<i8>(123) invokes bit limited operations instead and the result is always the same bit size.

So:

Code: [Select]

i32 a = 1 + 257; // Fine.
i8 b = cast<i8>(4 + 254); // Will store 2 done with big int, then converted to i8
i8 c = 1 + 257; // Compile time error
i8 d = cast<i8>(4) + cast<i8>(254); // Also 2, done with 8 bit maths.
f32 e = 1.0 * 2.0; // calculated using f64, then converted to f32
f64 f = 1.0;
f32 g = f * 2.0; // Compile time error, needs truncating cast
f32 h = cast<f32>(f * 2.0);
f32 i = cast<f32>(92.23) * cast<f32>(281.323); // Done with f32 maths.


[bas]

Constants are one area where C2 places more focus on compile-time than C. So

Code: [Select]

u8 a = 300;
Will just result in an error. This sounds harsh at first, but there is never a reason to write code like this.
This analysis is already implemented (for integers) and can be seen in the unit tests as well. C2 is a
strongly typed language, so the value should match the type instead of deriving the type from the value.

I think binary notation is already present as well (was already in Clang base).

I'll put this on the lower priority stack..

[lerno]

Yes most of this is already in the Clang lexer, so we get them "for free". But it should be documented.