[22] Byte code backward compatibility for compilation targets < 22 violated with '-proceedOnError', because parser falsely identifies unnamed class

[kriegaex]

[22] Byte code backward compatibility for compilation targets < 22 violated with '-proceedOnError', because parser falsely identifies unnamed class

[kriegaex]

Just in case you are wondering how I found such a weird example: In AspectJ, an old regression test ensuring compatibility between AJC and ECJ started to fail, because ECJ now behaves differently than before.

[stephan-herrmann]

This is a tricky one.

First observation: our grammar lacks suitable /:$compliance 22:/ declarations for this feature, but even with that, the example is parsed as an implicitly declared class. Only DiagnoseParser uses that information in order to produce suitable error messages (see usage of Parser.rules_compliance).

The core problem is: syntactically blahblahpackage pack; leaves no doubt that this is a variable declaration, and since we are not in a method context it must be a field declaration, which can only happen in a type declaration, explicit or implicit.

some ideas:
(1) should Parser.parse() directly check act similar to how DiagnoseParser does it? But then what?

(2) should we insert an empty token to the grammar, like:

ImplicitlyDeclaredClassBodyDeclarations ::= ClassMemberDeclaration StartImplicitType ImplicitlyDeclaredClassBodyDeclarations

Then we could let StartImplicitType trigger a consume method that does - what?

• discard the previously parsed ClassMemberDeclaration?
• reset stacks? which? how to ensure a consistent state?

(3) perhaps it's enough to make Parser.consumeInternalCompilationUnitWithPotentialImplicitlyDeclaredClass() conditional like this:

• if the feature is not enabled, then
  • if we find exactly one type declaration, we could promote this to the toplevel of the CU, and then
    • report all fields and methods found outside the class as misplaced constructs

@mickaelistria as the author of Parser.consumeInternalCompilationUnitWithPotentialImplicitlyDeclaredClass(), do you want to follow up along the lines of idea (3)?

[mickaelistria]

Sorry, I don't plan to work on it on short term.