Conform non-suffixed integer literals

[fairywreath]

Fixes #5458.

Make non-suffixed integer literals conformant to the C++ standard. The type of a decimal non-suffixed integer literal is the first integer type from the list [int, int64_t] which can represent the specified literal value. If the value cannot fit, the literal is represented as an uint64_t and a warning is given. The type of hexadecimal non-suffixed integer literal is the first type from the list [int, uint, int64_t, uint64_t] that can represent the specified literal value. The current non-suffixed behavior forces all integer literals to be represented as signed 32 bit integers.

The change consists of:

• Implementation in the parser with a new "integer is too large" warning, similar to clang and gcc
• Tests modification to properly test the new behaviour
• Documentation changes

Unfortunately there is an edge case when parsing -9223372036854775808(smallest int64 value). Because the lexer handles the negative(-) part of the literal separately. 9223372036854775808 is parsed by itself and it exceeds 9223372036854775807(largest int64 value), and a warning is emitted although it should not as -9223372036854775808 is within the range of int64 . When negation is parsed the value will still be properly assigned to -9223372036854775808. This compiler warning is also seen in clang and gcc. A proper fix for this would require lexer changes.

[CLAassistant]

All committers have signed the CLA.

[csyonghe]

Looks good to me, thank you for the fixes!

We don’t need to address in this PR, but the change does reveal that we are missing a check during coercion of integer literals when the literal is out of range.

for example, we should still warn when the user writes
int x=0xffffffffffff;

But this check can’t be done in the lexer and needs to happen during coerce().

[csyonghe]

Mark the PR as a breaking change because some corner case behaviors around literal types are changed.

[csyonghe]

The tests/slang-extension/atomic-int64-byte-address-buffer test needs to be updated as well.

[fairywreath]

Regarding coercion,

x=0xffffffffffff does give a warning:

1.slang(34): warning 30081: implicit conversion from 'int64_t' to 'int' is not recommended
    int x = 0xffffffffffff;
            ^~~~~~~~~~~~~~

But there is a weird issue when coercing UINT64_MAX which I have written down here #5728 which I fill fix in the future.
The current(without this PR's changes) behavior also does not give any warning, while it should give the "integer literal truncated" warning.

[csyonghe]

Looks good to me. Thank you for fixing the tests!