[TPL2] Should we use 32 bit or 64 bit integers by default?

[lmwnshn]

I think this slipped through.

We generate untyped TPL code that contains integer literals. We later parse and re-type the generated TPL code. These integer literals need to get assigned a type.

The default in TPL1 was to have 64-bit integers. The default in TPL2 was to have 32-bit integers.

This is a problem for the bigint test, because then it doesn't parse the integer literal correctly. This was remedied with the above "hack".

I think a cleaner solution would probably be to extend TPL's parser to have a L suffix for 64-bit integers (in which case LitExpr itself would need to be extended with a bit more metadata), or to move to 64-bit integers by default again. I don't know if the latter has performance or frame size implications, I think @pmenon at the time said "whatever makes it easier for you".

A lot of ASAN errors that me and @tanujnay112 ran into while porting TPL2 was caused by having 32-bit integers where 64-bit integers were expected and vice versa.

The most recent victim of integer sizes is #1044.

[lmwnshn]

We discussed this today. We think the right way to do this is:

1. TPL parses integers to 64-bit in LitExpr (so 64-bit default).
2. Sema is where the type of the LitExpr gets resolved. But this is quite an involved change.

[lmwnshn]

This issue claims another victim @17zhangw . Should probably increase priority a little..

[lmwnshn]

@pmenon has a fix for this in his repo, @lmwnshn to look at it.