#11105 Add syntax errors for unsigned literals > UInt128

[ScottPJones]

Previously, these unsigned literals would get promoted from an unsigned integer to a signed type,
which could lead to errors.
It is safer to give a syntax error, while the user can still explicitly get a BigInt value using hex, octal or binary notation by doing big"0x...." instead.

[pao]

cf #11105

In order to get the auto-close behavior, the commit message needs the word "fixes" or "closes" before the cross-reference. It's generally better to put that in the descriptive part of the commit message rather than the title line (but that's not a rigorous rule).

Probably needs a check over from @JeffBezanson since it touches the parser, and cc @jakebolewski as a heads up for JuliaParser.jl.

[ScottPJones]

@pao Thanks for the continued advice! I actually don't even know what you mean by the auto-close behavior, or how to separate out a title line from a descriptive part of a commit message... I just do git commit -a -m "message"

[pao]

If you have a "reasonable" git installation, for some definition of reasonable, you will get an editor pop up if you leave off the -m "message", which allows you to enter a more detailed commit message:

parser: syntax error for large hex literals #try to keep this short for git log --oneline

Modifies the parser to throw a syntax error once a hex integer literal cannot
be represented as a `Uint128`, and tests for that behavior.

Fixes #11105.

With the "fixes"/"closes"/"fix" bit in there, if this pull request is merged, the other issue will automatically be closed, which besides adding traceability is rather convenient.

[ScottPJones]

Hmmm.... something must be wrong with my installation then... it brings up Aquamacs, but the git commit command has already ended with an error...

ScottsRetinaMBP:j scott$ git commit -a
Aborting commit due to empty commit message.

[pao]

http://superuser.com/questions/180799/using-aquamacs-for-editor-in-subversion/180818#180818

[StefanKarpinski]

Seems like just deleting these would be better, no?

[ScottPJones]

OK, sure, will do... thanks!

[jakebolewski]

@ScottPJones this should throw a deprecation warning, not an error at this point (to follow our deprecation policy). See the other instances of throwing deprecated syntax warnings in this file.

The tests can also be removed completely.

[StefanKarpinski]

@jakebolewski, I kind of doubt that there's much code relying on this though – having hex BigInt literals is pretty strange (which is why we're removing it), and it would never happen at runtime since it is a parse time error.

[jakebolewski]

Why not deprecate the behavior of parsing signed BigInt's as well as unsigned ones? It would be great to remove the BigInt dependency from the frontend.

[tkelman]

Why not deprecate the behavior of parsing signed BigInt's as well as unsigned ones? It would be great to remove the BigInt dependency from the frontend.

I'd be greatly in favor of that, but that probably doesn't need to be done within the same PR?

[jakebolewski]

No you are right, but if we were going to deprecate parsing BigInt literals, it would make sense to do so for both the signed and unsigned forms.

[StefanKarpinski]

Let's stick with one thing at a time – everyone agrees that parsing long unsigned literals as BigInts is a bad idea, so let's delete it. I for one, am not convinced yet that we want to get rid of parsing large signed literals as BigInts.

[ScottPJones]

I agree with @StefanKarpinski on not (yet) being convinced of getting rid of parsing large signed literals... I mainly brought this up because of the inconsistency and potential surprise of the unsigned to signed types... but I also understand @jakebolewski 's concern about dependencies... since there is always the option of using big"... very long signed literal ...", and I doubt anyone (except the test cases!) are actually depending on long signed literals... maybe I'd lean (in another PR, of course), to removing all conversions to big types (what about conversions to BigFloats? ;-) I don't understand there why there's a Int128, but no "double double" Float128 type... underlying compiler support?

I'll remove the old tests, change to deprecation warnings, possibly fix up the tests I added (how do you test for a deprecation warning? I know @test and @test_throws so far...), hopefully this PR will be good to go then...

Thanks everybody!

[jakebolewski]

Thanks @ScottPJones for the update. There has been talk of Float80 / Float128 support (linking to GNU libquadmath). See issue #757.