Investigate if ECJ's parser be simplified by incorporating overlooked last minute spec revisions #1045

[stephan-herrmann]

WIP regargding https://github.com/eclipse-jdt/eclipse.jdt.core/issues/1045

@srikanth-sankaran this draft demonstrates that much of our solution can perhaps be found in JLS indeed:

Looking at the current spec, I find exactly three rules that may branch into LambdaExpression:

• Expression:
  • LambdaExpression
• CastExpression:
  • ( ReferenceType {AdditionalBound} ) LambdaExpression
• ConditionalExpression:
  • ConditionalOrExpression ? Expression : LambdaExpression

Much to my surprise this is accepted by jikespg, with 1.5 caveats:

• I haven't yet tried to multiply this into all our variants of rule CastExpression
• Also Expression is 2 rules (Expression and Expression_NotName) in our grammar, but that part seems to work

Results so far:

• jikespg accepts
• I had to disable where Scanner checks maybeAtLambdaOrCast() because it checks for a conflict we no longer have.
• with this ..compiler.regression.TestAll at 23 gives 51 failures, which doesn't look to bad, if you ask me :)

[stephan-herrmann]

No test results, because now the compiler can't compile itself ;-P

[srikanth-sankaran]

WIP regargding #1045

@srikanth-sankaran this draft demonstrates that much of our solution can perhaps be found in JLS indeed:

Thanks, I will review this next week -