[GITHUB-9056] Using sharp(er) classpath when rename refactoring.#9069
[GITHUB-9056] Using sharp(er) classpath when rename refactoring.#9069lahodaj merged 1 commit intoapache:masterfrom
Conversation
lahodaj
added
the
Java
mbien
added
the
ci:dev-build
|
can confirm that this fixes the issue, I could rename the (heavily used) utility method with all projects open. |
| switch (p) { | ||
| case PRECHECK: | ||
| case FASTCHECKPARAMETERS: | ||
| return JavaSource.forFileObject(docTreePathHandle != null? docTreePathHandle.getTreePathHandle().getFileObject() | ||
| : treePathHandle.getFileObject()); | ||
| case PREPARE: | ||
| case CHECKPARAMETERS: | ||
| if(treePathHandle != null && treePathHandle.getKind() == Tree.Kind.LABELED_STATEMENT) { | ||
| return JavaSource.forFileObject(treePathHandle.getFileObject()); | ||
| } | ||
| ClasspathInfo cpInfo = getClasspathInfo(refactoring); | ||
| JavaSource source = JavaSource.create(cpInfo, docTreePathHandle != null? docTreePathHandle.getTreePathHandle().getFileObject() | ||
| : treePathHandle.getFileObject()); | ||
| return source; | ||
|
|
||
| } | ||
| throw new IllegalStateException(); | ||
| return JavaSource.forFileObject(docTreePathHandle != null? docTreePathHandle.getTreePathHandle().getFileObject() | ||
| : treePathHandle.getFileObject()); |
There was a problem hiding this comment.
i suppose this used to be an optimization to create a smaller CP for inline rename?
i tried to look through history and the switch slowly grew over time
https://github.com/emilianbold/netbeans-releases/commit/0a558e4f1980436335f260a36d35658e55c4dd64
https://github.com/emilianbold/netbeans-releases/commit/f2d147e5a942e3446dbc94f8b8f90e4867257c80
There was a problem hiding this comment.
TBH, I am not sure what was the idea. I see the label rename refactoring probably does not have tests, I'll see if there's a meaningful way to add some.
|
Ok. If there are no objections, I'll merge. Of course, if something breaks (too much) anyone should feel free to revert. Thanks!! |
2 participants
The Java refactoring is sometimes using class path (
ClasspathInfo) that is, to me, extremely weird. In the specific case of #9056, theClasspathInfoused to processGspIndenterdoes not in some cases contain thelexermodule, while thegroovy/groovy.gspdefinitely lists it as a dependency.The consequence of that is that there are compile-time errors in the file(s) with this broken class path. Sometimes, it may lead to "catastrophic" failures like:
https://bugs.openjdk.org/browse/JDK-8373094
but even if it does not, wrong class path is likely to lead to weird effects. Like, in the test for the PR,
testComplexRename1, insidemain.Main, not onlytest(Side)will be renamed, but alsotest(String)will be renamed with the current state, as the classpath when analyzingmain.maindoes not containside.The goal of this PR is to use class path that is more sensible for the rename refactoring.
^Add meaningful description above
Click to collapse/expand PR instructions
By opening a pull request you confirm that, unless explicitly stated otherwise, the changes -
Please make sure (eg.
git log) that all commits have a valid name and email address for you in the Author field.If you're a first time contributor, see the Contributing guidelines for more information.
If you're a committer, please label the PR before pressing "Create pull request" so that the right test jobs can run.
PR approval and merge checklist:
If this PR targets the delivery branch: don't merge. (full wiki article)