RFR: 8027682: javac wrongly accepts semicolons in package and import decls [v4]

Vicente Romero vromero at openjdk.org
Thu Feb 9 04:14:42 UTC 2023


On Tue, 7 Feb 2023 19:51:51 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> JLS [§7.3](https://docs.oracle.com/javase/specs/jls/se19/html/jls-7.html#jls-7.3) specifies that while a lone semicolon is a valid _TopLevelClassOrInterfaceDeclaration_, it is not a valid _ImportDeclaration_. Therefore, if we see a lone semicolon while looking for the next import statement we have to advance and accept a class declaration, and we can therefore no longer accept any further `import` statements.
>> 
>> However, the compiler was allowing this, for example:
>> 
>> package p; import X; ;;; import Y; class Foo {}
>> 
>> The bug is that the parser was switching out of "look for imports" mode after parsing a valid class declaration, but it was not switching out of "look for imports" mode after parsing a lone semicolon.
>> 
>> The fix to `JavacParser.java` is easy, however it also requires these adjustments to unit tests:
>> 
>> * Test `tree/T6963934.java` must go away, because it is verifying a bug that only happens when the above bogus input is successfully parsed, and this can no longer happen.
>> * A bug in `lib/types/TypeHarness.java` was uncovered and fixed; it was inserting an extra semicolon.
>> * The following bugs, which check invalid syntax within import statements, now generate different parse errors and therefor needed their "golden output" updated:
>>   * annotations/typeAnnotations/failures/AnnotatedImport.java
>>   * annotations/typeAnnotations/failures/AnnotatedPackage1.java
>>   * annotations/typeAnnotations/failures/AnnotatedPackage2.java
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust unit test to accomodate spelling change in previous commit.

I was playing with this test case:


import java.util.NO;
    ;
import java.io.NO;

only the new `extraneous semicolon` error is reported but the compiler doesn't report the fact that there is no class named NO inside of `java.util` or `java.io` I think that those other errors should be reported too

-------------

PR: https://git.openjdk.org/jdk/pull/12448


More information about the compiler-dev mailing list