Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8226216: parameter modifiers are not visible to javac plugins across compilation boundaries #1890

Closed
wants to merge 5 commits into from

Conversation

@lgxbslgx
Copy link
Member

@lgxbslgx lgxbslgx commented Dec 24, 2020

Hi all,

javac fails to read modifiers from the MethodParameters attribute in class files, which prevents plugins from accessing those modifiers across compilation boundaries. Because com.sun.tools.javac.jvm.ClassReader doesn't read and store the access flags(modifiers) from MethodParameters attribute.

This patch fixes it and adds a corresponding test case. All the existing tests of javac passed locally.

Thank you for taking the time to review.

Best Regards.


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8226216: parameter modifiers are not visible to javac plugins across compilation boundaries

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/1890/head:pull/1890
$ git checkout pull/1890

Update a local copy of the PR:
$ git checkout pull/1890
$ git pull https://git.openjdk.java.net/jdk pull/1890/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 1890

View PR using the GUI difftool:
$ git pr show -t 1890

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/1890.diff

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Dec 24, 2020

👋 Welcome back lgxbslgx! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

Loading

@openjdk openjdk bot added the rfr label Dec 24, 2020
@openjdk
Copy link

@openjdk openjdk bot commented Dec 24, 2020

@lgxbslgx The following label will be automatically applied to this pull request:

  • compiler

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

Loading

@openjdk openjdk bot added the compiler label Dec 24, 2020
@mlbridge
Copy link

@mlbridge mlbridge bot commented Dec 24, 2020

Loading

Copy link
Contributor

@jonathan-gibbons jonathan-gibbons left a comment

I've noted a couple of minor issues in the test.
I'll leave it to other javac folk to decide the merits of the change to ClassReader.
Note that the MethodParameters attribute may not always be present.

Loading

* published by the Free Software Foundation. Oracle designates this
* particular file as subject to the "Classpath" exception as provided
* by Oracle in the LICENSE file that accompanied this code.
Copy link
Contributor

@jonathan-gibbons jonathan-gibbons Dec 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tests should not contain the text Oracle designates ... this code. or the immediately preceding whitespace.

Loading

Copy link
Member Author

@lgxbslgx lgxbslgx Dec 25, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

Loading

}

@Test
public void testParameterModifiersNotVisiable() throws Exception {
Copy link
Contributor

@jonathan-gibbons jonathan-gibbons Dec 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

spelling: should be "Visible"

Loading

Copy link
Member Author

@lgxbslgx lgxbslgx Dec 25, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

Loading

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Jan 22, 2021

@lgxbslgx This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

Loading

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Feb 19, 2021

@lgxbslgx This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it!

Loading

@bridgekeeper bridgekeeper bot closed this Feb 19, 2021
@lgxbslgx
Copy link
Member Author

@lgxbslgx lgxbslgx commented Apr 22, 2021

/open

Loading

@openjdk openjdk bot reopened this Apr 22, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Apr 22, 2021

@lgxbslgx @HostUserDetails{id=13688759, username='lgxbslgx', fullName='null'} this pull request is now open

Loading

.run()
.writeAll()
.getOutputLines(Task.OutputKind.STDERR);
List<String> firstExpected = Arrays.asList("x [final]", "x [final]");
Copy link
Member

@jbf jbf Apr 27, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are there supposed to be two "x [final]" in the first output?

Loading

Copy link
Member Author

@lgxbslgx lgxbslgx Apr 27, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because it has two source files. Please see the code snippet of the method JavaCompiler.enterTrees.

public List<JCCompilationUnit> enterTrees(List<JCCompilationUnit> roots)
// ignore other code.
        if (!taskListener.isEmpty()) {
            for (JCCompilationUnit unit: roots) {
                TaskEvent e = new TaskEvent(TaskEvent.Kind.ENTER, unit);
                taskListener.finished(e);
            }
        }
//  ignore other code.
}

The task listener is called every time there is a JCCompilationUnit.

Loading

@lgxbslgx
Copy link
Member Author

@lgxbslgx lgxbslgx commented May 11, 2021

Ping. Could I ask your help to review this patch? Thanks a lot.

Loading

List<String> secondOutput = new JavacTask(tb)
.options("--processor-module-path", "plugin", "-Xplugin:P",
"-parameters", "-classpath", "test")
.files("test/B.java")
Copy link
Contributor

@lahodaj lahodaj May 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the test really test the ClassReader behavior? It seems B is always originating in the source, and the test is looking at a parameter from the B file? Maybe the idea was test/A.java would be used here?

Loading

Copy link
Member Author

@lgxbslgx lgxbslgx May 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be test/A.java. Fixed.

Loading

Elements elements = javacTask.getElements();
TypeElement typeElement = elements.getTypeElement("B");
for (Element m : typeElement.getEnclosedElements()) {
if (m instanceof ExecutableElement) {
Copy link
Contributor

@lahodaj lahodaj May 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this is a test, not so huge deal, but it might be better to do filtering using ElementFilter.methodsIn - it is easier to use than Element.getKind(), and safer than instanceof (which is not very much safe for Elements).

Loading

Copy link
Member Author

@lgxbslgx lgxbslgx May 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your suggestion. I revised the code by using ElementFilter.methodsIn.

Loading

Copy link
Contributor

@lahodaj lahodaj left a comment

Looks good to me.

Loading

@openjdk
Copy link

@openjdk openjdk bot commented May 11, 2021

@lgxbslgx This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8226216: parameter modifiers are not visible to javac plugins across compilation boundaries

Reviewed-by: jlahoda

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 299 new commits pushed to the master branch:

  • 7a0a57c: 8266820: micro java/nio/SelectorWakeup.java has wrong copyright header
  • d0daa72: 8266857: PipedOutputStream.sink should be volatile
  • 381de0c: 8266753: jdk/test/lib/process/ProcTest.java failed with "Exception: Proc abnormal end"
  • 2d2cd78: 8266761: AssertionError in sun.net.httpserver.ServerImpl.responseCompleted
  • 9c9c47e: 8266813: Shenandoah: Use shorter instruction sequence for checking if marking in progress
  • 0344e75: 8266794: Remove dead code notify_allocation_jvmti_allocation_event
  • 9e6e222: 8266892: avoid maybe-uninitialized gcc warnings on linux s390x
  • 6575566: 8266787: Potential overflow of pointer arithmetic in G1ArchiveAllocator
  • 8468001: 8263452: Javac slow compilation due to algorithmic complexity
  • 67cb22a: 8266601: Fix bugs in AddLNode::Ideal transformations
  • ... and 289 more: https://git.openjdk.java.net/jdk/compare/191f1fc46c30f7e92ba09d04bc000256442e64ed...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@jonathan-gibbons, @lahodaj) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

Loading

@openjdk openjdk bot added the ready label May 11, 2021
@lgxbslgx
Copy link
Member Author

@lgxbslgx lgxbslgx commented May 11, 2021

@lahodaj Thanks for your review. Could I get your help to sponsor this patch?

/integrate

Loading

@openjdk openjdk bot added the sponsor label May 11, 2021
@openjdk
Copy link

@openjdk openjdk bot commented May 11, 2021

@lgxbslgx
Your change (at version 560f0ab) is now ready to be sponsored by a Committer.

Loading

@lahodaj
Copy link
Contributor

@lahodaj lahodaj commented May 12, 2021

/sponsor

Loading

@openjdk openjdk bot closed this May 12, 2021
@openjdk openjdk bot added integrated and removed sponsor labels May 12, 2021
@openjdk
Copy link

@openjdk openjdk bot commented May 12, 2021

@lahodaj @lgxbslgx Since your change was applied there have been 326 commits pushed to the master branch:

  • 69daedf: 8266845: Shenandoah: Simplify SBS::load_reference_barrier implementation
  • 7433821: 8250658: Performance of ClipFlatOval Renderperf test is very low
  • 4727187: 8266567: Fix javadoc tag references in sun.management.jmxremote.ConnectorBootstrap
  • 11759bf: 8266798: C1: More types of instruction can also apply LoopInvariantCodeMotion
  • dcf250d: 8233378: CHT: Fast reset
  • f3b510b: 8266923: [JVMCI] expose StackOverflow::_stack_overflow_limit to JVMCI
  • 548899d: 8266189: Remove C1 "IfInstanceOf" instruction
  • b46086d: 8266874: Clean up C1 canonicalizer for TableSwitch/LookupSwitch
  • 97367c0: 8266808: Search label still uses old search field id
  • 06d7602: 8261158: JVMState should not be shared between SafePointNodes
  • ... and 316 more: https://git.openjdk.java.net/jdk/compare/191f1fc46c30f7e92ba09d04bc000256442e64ed...master

Your commit was automatically rebased without conflicts.

Pushed as commit accbfea.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Loading

@lgxbslgx lgxbslgx deleted the JDK-8226216 branch May 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
4 participants