Short.MinValue, Integer.MinValue, and Long.MinValue aren't expressable as decimal literals

[AnthonyDGreen]

This applies to all the signed integral types (and probably Decimal) but using Short for an example, -32_768S will report an overflow error. The reason is that it's not a single token with a negative value but the negation of a token with a positive value. And since 32_768S is above Short.MaxValue the scanner reports an overflow error.

This is all technically correct. But frustrating. It looks like the scanner can look behind 1 character to detect this scenario and not report the warning and we can give the token its "true value". Then in constant folding where we would otherwise report an overflow error (because -(-32_768S) is invalid) we could detect that the LiteralExpressionSyntax has a negative value, but its token does not have a base other than decimal (the only way today in VB that a literal token could have a negative value) and elide what would be an extra negation. In short, move the negation from the binder to the scanner with secret handshakes. I think this could be done without impacting performance since normally in the presence of errors we would just stop compilation, so this recovery code would only be in the failure path anyway.

We could do this for all the signed integral types and Decimal.

This would save me having to explain to users why this intuitively correct expression reports an error and is a neat example of VBs attention to detail.