search

qwertie / ecsharp

Home of LoycCore, the LES language of Loyc trees, the Enhanced C# parser, the LeMP macro preprocessor, and the LLLPG parser generator.
http://ecsharp.net
Other
177 stars 25 forks source link

Add BigInteger literals to LES #42

Closed jonathanvdc closed 8 years ago

jonathanvdc commented 8 years ago

This PR adds support for both explicit and implicit BigInteger literals to both LESv2 and LESv3. Explicit BigInteger literals are suffixed by z or Z. Implicit BigInteger literals are unsuffixed integer literals that do not fit in a ulong or a long, depending on the literal's sign.

Note that this PR will make test Les3LexerTests.TestShebang fail. I suspect that this cannot be attributed to any of the changes to source files in this PR, because I can reproduce the issue on the 'master' branch.

Steps to reproduce:

./Bin/Release.NET45/LLLPG.exe Core/Loyc.Syntax/LES/Les3Lexer.ecs --outlang=cs --outext=out.cs
xbuild /p:Configuration=Release.NET45 Loyc-Slim.sln
./Bin/Release.NET45/Tests.exe 3

Les3LexerTests.TestShebang then fails with

Les3LexerTests.TestShebang
AssertionException while running Les3LexerTests.TestShebang:
  Expected: Keyword
  But was:  Shebang

I'm assuming that I either gave LLLPG bad command-line arguments, or that you forgot to push Core/Loyc.Syntax/LES/Les3Lexer.out.cs at some point. I don't know how to fix the failing test, though.

Do you think this PR is acceptable as-is? If not, what should I change?

qwertie commented 8 years ago

I guess I should have asked you specifically not to touch the LESv3 parser; I have already changed it a lot on my machine to support the "unified" custom literal parsing system, and your changes are not compatible. Please remove those changes - I will personally add BigInteger support to v3 after I merge this PR.

qwertie commented 8 years ago

I remember seeing TestShebang fail at some point in the past, so yeah, I probably just forgot to commit something.

jonathanvdc commented 8 years ago

I've pushed some new commits that should address your concerns.

One of those commits changes a test case which used to assert that 0x1_FFFF_FFFF_0000_0000 is an erroneous token in EC#. The test now asserts that 0x1_FFFF_FFFF_0000_0000 is a valid BigInteger literal, instead.

I had to do this because it turned out that I had unintentionally added implicit BigInteger literals to EC# by updating the LES integer parsing logic. I don't think that implicit BigInteger literals break backward compatibility in any way, though. So I figured that I might as well let the EC# implicit BigInteger literals stay. Are you okay with that?

qwertie commented 8 years ago

Hah! Accidental BigInts in EC#, that's funny. I guess we can let that slide. (Note to self, we need to support z suffix too...)