Literal: Check Literal::Integer at limits and when overflowing

[Hywan]

First, Literal::Integer was a u64 which is wrong regarding the specification (https://github.com/php/php-langspec/blob/master/spec/05-types.md#the-integer-type):

This type is binary, signed, and uses twos-complement representation for negative values. The range of values that can be stored is implementation-defined; however, the range [-2147483648, 2147483647], must be supported. This range must be finite.

Second, new test cases are added to test the limit values of integer representation (before and after overflow).

Third, only decimal will overflow to reals. The specification says:

Certain operations on integer values produce a mathematical result that cannot be represented as an integer.
[…]
In such cases, the computation is done as though the types of the values were float with the result having that type.

It does not mention the parsing behavior. The Zend Engine will apply the overflow from integer to real for all “number” representations, aka binary, octal, decimal and hexadecimal. However, the f32::from_str_radix and f64::from_str_radix functions have been removed from Rust std (see https://internals.rust-lang.org/t/deprecate-f-32-64-from-str-radix/2405) for good reasons I have to admit. So I consider this is an edge case and only the support for decimal overflow is added.

If a volunteer woud like to reimplement a safe and stable from_str_radix for f64 (for 2, 8, 10 and 16 radices only), good! I am pretty sure it will be hard (to write and to test). If this is a very important conformance issue, let's open an issue.

Thoughts @jubianchi, @nikic?

[nikic]

I suspect that overflowing hex literals are more common than one might think due to people trying to use unsigned 64-bit literals, like 0xffffffffffffffff, which are actually floating point literals. Btw, I think the hex/bin/oct float literal parsing in PHP is actually broken (not accurate)...

[Hywan]

@nikic I am pretty sure it is. Even in Rust, the f64.from_str_radix with a decimal representation is not accurate. I wonder if we should land inaccurate code or not land anything at all. By the way, this is a good opportunity for a Rust contribution. We can release it as a standalone crate and use it inside tagua/parser. Thoughts?

[Hywan]

We can use std::i64::MAX here.

[Hywan]

A new issue has been created to split the work. Let's merge this one and address other number representations in new PR.