Parser modification to handle UAdd in front of int constant #215

ychenfo · 2022-03-08T03:12:21+08:00

ychenfo commented

2022-03-08 03:12:21 +08:00

Currently things like int64(+9223372036854775807) (which is i64::MAX), will break with Integer out of bound.

While this can be explained as: 9223372036854775807 is not directly annotated with int64 so the compiler is handling it as a i32, I think this might be a bit inconsistent with the cases of the negative signs, where int64(--9223372036854775807) does not break, so I attempted to fix this in this PR.

If the current behavior is not desirable, this small patch should be able to fix that.

Currently things like ``int64(+9223372036854775807)`` (which is `i64::MAX`), will break with `Integer out of bound`. While this can be explained as: `9223372036854775807` is not directly annotated with `int64` so the compiler is handling it as a `i32`, I think this might be a bit inconsistent with the cases of the negative signs, where `int64(--9223372036854775807)` does not break, so I attempted to fix this in this PR. If the current behavior is not desirable, this small patch should be able to fix that.

ychenfo force-pushed uadd_int_parser_fix from 17aa9f1ce8 to e641fa6ebc

2022-03-08 19:24:01 +08:00

Compare

ychenfo commented

2022-03-08 19:24:59 +08:00

force-pushed to rebase on the latest master branch

sb10q merged commit e266d3c2b0 into master

2022-03-09 10:46:58 +08:00

sb10q deleted branch uadd_int_parser_fix

2022-03-09 10:46:58 +08:00

sb10q commented

2022-03-09 10:55:31 +08:00

I think this might be a bit inconsistent with the cases of the negative signs, where int64(--9223372036854775807) does not break

I don't understand why it does not and also does not produce a silent int32 overflow. Is it because the parser handles both minus signs and puts them into the final value?

> I think this might be a bit inconsistent with the cases of the negative signs, where int64(--9223372036854775807) does not break I don't understand why it does not and also does not produce a silent int32 overflow. Is it because the parser handles both minus signs and puts them into the final value?

ychenfo commented

2022-03-09 11:50:23 +08:00

I don't understand why it does not and also does not produce a silent int32 overflow. Is it because the parser handles both minus signs and puts them into the final value?

Thanks for merging! Yes, the way the current parser does is like a small constant optimization for integer constants, so the two minus signs are handled directly in the parsing phase and will not cause problem in the later type check and codegen phase.

> I don't understand why it does not and also does not produce a silent int32 overflow. Is it because the parser handles both minus signs and puts them into the final value? Thanks for merging! Yes, the way the current parser does is like a small constant optimization for integer constants, so the two minus signs are handled directly in the parsing phase and will not cause problem in the later type check and codegen phase.

Sign in to join this conversation.

No reviewers