Fix on missing warning on some cases of integer literal coercion #5728

[zlatinski]

Fix missing warnings on:

int x3 = 18446744073709551615;
int x4 = 0xFFFFFFFFFFFFFFFF;

fixes #5728

[csyonghe]

Can you add a test?

I am not sure I understand what is being fixed here. We don’t want a warning for int64_t v = -9223372036854775808 and I am not seeing how the patch fixes that.

[zlatinski]

It is fixing the issues reported:
int x3 = 18446744073709551615;
int x4 = 0xFFFFFFFFFFFFFFFF;

We don’t want a warning for int64_t v = -9223372036854775808 and I am not seeing how the patch fixes that.
Are you saying that we have an issue with the above assignment? Let me check ...

[csyonghe]

I am just seeing the comment being deleted is discussing this case, so it is best to verify things are working as expected with tests.

[zlatinski]

I have the test added for the integer literal coercion.

[jkwak-work]

Change looks good to me.

[csyonghe]

The fundamental problem of this issue is that we are trying to determine the type of a literal or issue a warning too early.
We should wait until the semantic checking stage to issue this kind of warnings.

When we parse the int literal, we just store the token into the AST, and parse the int into a uint64_t field. Let's not determine the type of the literal expr yet.

Then when we are checking the expr in SemanticExprVisitor, we can always fold the OperatorExpr(IntLiteralExpr) into a single IntLiteralExpr, and then do the checking on the IntLiteralExpr to see if it is out of bounds.