RFR: 8305671: javac rejects semicolons in compilation units with no imports [v2]
F15T33N Packer
f15t33n.company at gmail.com
Tue Apr 18 02:13:19 UTC 2023
Thanks, I'll take a look.
SP LLC
On Monday, April 17, 2023, 8:46 PM, Archie L. Cobbs <duke at openjdk.org> wrote:
On Mon, 17 Apr 2023 23:43:20 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:
>> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Use ToolBox and add more tests per review suggestion.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3860:
>
>> 3858: break;
>> 3859: nextToken();
>> 3860: }
>
> This might work, but it "feels" wrong (as in, a hack) to leave an extra semicolon around.
>
> Yes, a package statement must be followed by a semicolon (line 3835) but after that can't you slurp up all the extra semicolons, and only report them if there is an import statement, and ignore them if there are no imports?
I'd rather not mess with it because the existing code is already a customized (i.e., not a straightforward parse) so that it can provide a more helpful error message when duplicate semicolons are found after import statements. See [JDK-8027682](https://bugs.openjdk.org/browse/JDK-8027682) and PR #12448. Doing what you suggest would probably be more straightforward but would risk breaking that.
> test/langtools/tools/javac/parser/ExtraPackageSemicolon.java line 42:
>
>> 40:
>> 41: public static void runTest(String filename, String source) throws Exception {
>> 42: final File sourceFile = new File(filename);
>
> As a matter of style, writing source code to `java.io.File` objects, this feels very old-school, but for a small test program like this, it's not awful.
>
> If this were any bigger, I'd suggest looking at the test `ToolBox` library and/or using `SimpleJavaFileObject` to use more common code idioms and support.
>
> As it is, I'd still suggest using `Files.writeString` to write each source.
> https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/nio/file/Files.html#writeString(java.nio.file.Path,java.lang.CharSequence,java.nio.charset.Charset,java.nio.file.OpenOption...)
I'll switch to using `ToolBox`.
> test/langtools/tools/javac/parser/ExtraPackageSemicolon.java line 45:
>
>> 43: System.err.println("writing: " + sourceFile);
>> 44: try (PrintStream output = new PrintStream(new FileOutputStream(sourceFile))) {
>> 45: output.println(source);
>
> This would be somewhat overly simplistic (but not wrong) if any source had newlines in it.
Fixed by using `ToolBox`.
> test/langtools/tools/javac/parser/ExtraPackageSemicolon.java line 65:
>
>> 63: runTest("Test2.java", "package p;;");
>> 64: runTest("Test3.java", "package p;; ;; ;; ;;; ;;; ;;; ;;");
>> 65: }
>
> I suggest including test cases where the package statement and semicolons are followed by something else, like an import declaration or a type declaration.
I'll add more tests, but extra semicolons prior to import statements aren't allowed; see [JDK-8027682].
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/13361#discussion_r1169404766
PR Review Comment: https://git.openjdk.org/jdk/pull/13361#discussion_r1169404540
PR Review Comment: https://git.openjdk.org/jdk/pull/13361#discussion_r1169405308
PR Review Comment: https://git.openjdk.org/jdk/pull/13361#discussion_r1169404706
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230418/54cee10d/attachment.htm>
More information about the compiler-dev
mailing list