JDK-8256950: Add record attribute support to symbol generator CreateSymbols #1480
Conversation
|
|
Webrevs
|
| @@ -959,6 +962,21 @@ private void addAttributes(ClassHeaderDescription header, | |||
| attributes.put(Attribute.NestMembers, | |||
| new NestMembers_attribute(attributeString, nestMembers)); | |||
| } | |||
| if (header.recordComponents != null && !header.recordComponents.isEmpty()) { | |||
ChrisHegarty
Nov 30, 2020
Member
I am not sure of the exact logic here, but it is perfectly fine for a record attribute to contain zero components, and for the class to still be considered a "record class". But maybe that is not all that significant here? I just want to call it out so that it is considered.
I am not sure of the exact logic here, but it is perfectly fine for a record attribute to contain zero components, and for the class to still be considered a "record class". But maybe that is not all that significant here? I just want to call it out so that it is considered.
|
|
|
Looks mostly OK; some minor comments inline. |
| "--add-exports", "jdk.javadoc/jdk.javadoc.internal.api=ALL-UNNAMED", | ||
| "--add-exports", "jdk.javadoc/jdk.javadoc.internal.tool=ALL-UNNAMED", |
jonathan-gibbons
Dec 1, 2020
Contributor
I'm surprised CreateSymbolsTest needs access to javadoc internals; is it because you're adding all of toolbox in lines 93, 94? Would it be better to filter out the classes you don't want to compile, such as JavadocTask and JavapTask ?
I'm surprised CreateSymbolsTest needs access to javadoc internals; is it because you're adding all of toolbox in lines 93, 94? Would it be better to filter out the classes you don't want to compile, such as JavadocTask and JavapTask ?
| import java.util.Set; | ||
| import java.util.stream.Collectors; | ||
| import java.util.stream.Stream; | ||
| import toolbox.JavacTask; | ||
| import toolbox.Task; | ||
| import toolbox.Task.Expect; | ||
| import toolbox.ToolBox; | ||
| import build.tools.symbolgenerator.CreateSymbols; | ||
| import build.tools.symbolgenerator.CreateSymbols.ClassDescription; | ||
| import build.tools.symbolgenerator.CreateSymbols.ClassList; | ||
| import build.tools.symbolgenerator.CreateSymbols.CtSymKind; | ||
| import build.tools.symbolgenerator.CreateSymbols.ExcludeIncludeList; | ||
| import build.tools.symbolgenerator.CreateSymbols.VersionDescription; | ||
| import java.util.Enumeration; | ||
| import java.util.jar.JarEntry; | ||
| import java.util.jar.JarFile; |
jonathan-gibbons
Dec 1, 2020
Contributor
weird order of imports
weird order of imports
| "}\n", | ||
| "t.Visible", | ||
| "package t;\n\n" + | ||
| "@java.lang.annotation.Retention(java.lang.annotation.RetentionPolicy.RUNTIME)\n" + | ||
| // "@java.lang.annotation.Retention(java.lang.annotation.RetentionPolicy.RUNTIME)\n" + //XXX |
jonathan-gibbons
Dec 1, 2020
Contributor
Is this line still supposed to be here?
Is this line still supposed to be here?
| @@ -261,7 +267,8 @@ void testAnnotations() throws Exception { | |||
| "}\n", | |||
| "t.Visible", | |||
| "package t;\n\n" + | |||
| "@java.lang.annotation.Retention(java.lang.annotation.RetentionPolicy.RUNTIME)\n" + | |||
| // "@java.lang.annotation.Retention(java.lang.annotation.RetentionPolicy.RUNTIME)\n" + //XXX | |||
jonathan-gibbons
Dec 1, 2020
Contributor
Is this line still supposed to be here?
Is this line still supposed to be here?
| } | ||
|
|
||
| @Test | ||
| // @Test XXX |
jonathan-gibbons
Dec 1, 2020
Contributor
Another XXX line
Another XXX line
| """ | ||
| \n\ | ||
| public static record R(int i, java.util.List<java.lang.String> l) { | ||
| \n\ | ||
| public R(int i, | ||
| java.util.List<java.lang.String> l); | ||
| \n\ | ||
| public final java.lang.String toString(); | ||
| \n\ | ||
| public final int hashCode(); | ||
| \n\ | ||
| public final boolean equals(java.lang.Object arg0); | ||
| \n\ | ||
| public int i(); | ||
| \n\ | ||
| public java.util.List<java.lang.String> l(); | ||
| } | ||
| """, |
jonathan-gibbons
Dec 1, 2020
Contributor
I don't understand why the lines with \n\ in a text block
I don't understand why the lines with \n\ in a text block
lahodaj
Dec 1, 2020
Author
Contributor
There is a combination of factors here:
-jcheck (AFAIK) does not allow trailing whitespaces, even not on otherwise empty lines inside textblocks
-textblocks only remove indentation that is common on all lines.
So, without having '\n', we would have to strip all the whitespace on the empty lines (to pass jcheck), which would mean the text block's content would no longer match the output. There are a few ways to solve this (almost surely an incomplete list):
-do some trick to have the common indent, but no trailing whitespace. '\n' is one of them.
-not indent the text block
-do some post-processing on the text block's value or the actual test output, to make them match
-not use textblocks
There is a combination of factors here:
-jcheck (AFAIK) does not allow trailing whitespaces, even not on otherwise empty lines inside textblocks
-textblocks only remove indentation that is common on all lines.
So, without having '\n', we would have to strip all the whitespace on the empty lines (to pass jcheck), which would mean the text block's content would no longer match the output. There are a few ways to solve this (almost surely an incomplete list):
-do some trick to have the common indent, but no trailing whitespace. '\n' is one of them.
-not indent the text block
-do some post-processing on the text block's value or the actual test output, to make them match
-not use textblocks
lahodaj
Dec 3, 2020
Author
Contributor
I stand corrected here - blank lines do not count when the common indent is computed. Removed here:
3aaaf28
I stand corrected here - blank lines do not count when the common indent is computed. Removed here:
3aaaf28
| if (createSymbols == null) { | ||
| System.err.println("Warning: cannot find CreateSymbols, skipping."); | ||
| return ; | ||
| } |
jonathan-gibbons
Dec 1, 2020
Contributor
I can believe this test is worth just a warning, because you're trying to reach into the make directory, but the subsequent checks for CreateSymbolsTestImpl.java and toolbox.* seem worthy of errors, not warnings. On the other hand, I accept that all of these checks are very unlikely to fail, so maybe it doesn't matter.
I can believe this test is worth just a warning, because you're trying to reach into the make directory, but the subsequent checks for CreateSymbolsTestImpl.java and toolbox.* seem worthy of errors, not warnings. On the other hand, I accept that all of these checks are very unlikely to fail, so maybe it doesn't matter.
| @@ -25,6 +25,10 @@ | |||
| * @test | |||
| * @bug 8072480 | |||
| * @summary Unit test for CreateSymbols | |||
| * @modules java.compiler | |||
| * jdk.compiler | |||
| * jdk.javadoc | |||
jonathan-gibbons
Dec 1, 2020
Contributor
See related comments in code ... seems strange to need jdk.javadoc.
See related comments in code ... seems strange to need jdk.javadoc.
| ).call(); | ||
| if (!res) { | ||
| throw new IllegalStateException("Cannot compile test."); | ||
| } | ||
| } | ||
|
|
||
| URLClassLoader cl = new URLClassLoader(new URL[] {testClasses.toUri().toURL(), compileDir.toUri().toURL()}); |
jonathan-gibbons
Dec 1, 2020
Contributor
line 132: the name of the local variable createSymbols seems more specific than the method might imply!
line 132: the name of the local variable createSymbols seems more specific than the method might imply!
|
Thanks for the comments Jon! I've tried to resolve them here: |
|
@lahodaj This change now passes all automated pre-integration checks. After integration, the commit message for the final commit will be: You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 2 new commits pushed to the
Please see this link for an up-to-date comparison between the source branch of this pull request and the
|
|
/reviewer credit jjg |
|
@lahodaj Reviewer |
|
/integrate |
|
@lahodaj Since your change was applied there have been 2 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 6eff931. |
Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change:
-updating and moving tests into test/langtools, so that it is easier to run them.
-fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway).
-fixing the -Xprint annotation processor to print record component annotations.
Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works.
Progress
Issue
Reviewers
Download
$ git fetch https://git.openjdk.java.net/jdk pull/1480/head:pull/1480$ git checkout pull/1480