Preserve the L suffix on converted long literals

[paulirwin]

Problem

LongLiteralExpressionVisitor stripped the trailing L/l from a Java long literal and emitted the remaining text verbatim, so the generated C# lost the suffix that makes it a long.

That produced code which does not compile. C# types a bare numeric literal as int, so:

long allOnes = 0xFFFFFFFFFFFFFFFFL;

converted to:

long allOnes = 0xFFFFFFFFFFFFFFFF;   // error CS0266: cannot implicitly convert 'ulong' to 'long'

Fix

• Re-append the L suffix when building the literal token.
• Strip the incoming L/l as a suffix rather than via a blanket Replace over the whole string, which was scanning every character of a value we echo back into the generated source.
• A hex literal above long.MaxValue stays invalid in C# even with the suffix, because the literal is typed by its magnitude. For that case emit the wrapped decimal value, which is the number Java means: 0xFFFFFFFFFFFFFFFFL → -1L.

Why it went unnoticed

The existing long-literal tests asserted only the parsed numeric Value, never the emitted token text — so a literal with a correct value but uncompilable text passed. The new cases assert Text.

Testing

• New VisitLiteralExpression_Long_PreservesSuffixInText theory covering hex, binary, octal, underscore separators, lowercase l, and both overflow boundaries.
• Extra VisitLiteralExpression_Long cases for the two's-complement and above-int.MaxValue values.
• Resources/LongLiterals.java wired into FullIntegrationTests, which compiles the generated C# and asserts its runtime output matches Java's.

Full suite: 378 passed, 0 failed (was 363).

Note on #128

The binary-literal crash originally reported in #128 (0b10, 0b100) no longer reproduces on master — it was fixed sometime after the 3.0.0 build in that report. Investigating it surfaced this adjacent defect in the long-literal path, which this PR fixes. Worth confirming whether #128 should now be closed.

🤖 Generated with Claude Code