Summary
go-to-definition can jump to the wrong line after renaming in another open tab.
Reproduction
- Open 2 tabs.
- In tab 1, keep a reference to a method or field defined in tab 2.
- In tab 2, rename something else that is not referenced in tab 1 and appears above the referenced symbol in the file.
- In tab 1, run
go-to-definition on the reference.
Expected
The editor jumps to the current declaration position.
Actual
The editor can jump to a stale offset, usually the line that matched before the rename/comment inserted extra lines above the declaration.
Suspected cause
RenameService.refreshState() builds updatedTopClasses from node.addUpdateNodes(...), which is based on usages of the renamed symbol. Only tabs whose root class appears in that set are refreshed (in RenameService.refreshTabs).
That means an open tab that references the renamed symbol may stay on an old cachedCodeInfo if its class is not included in updatedTopClasses, even though the code layout changed above the referenced declaration.
Other thoughts
My guess is that adding all of the tabs that have a reference to the class, and not just the method/field would fix the issue, but might not be the best because it would refresh classes that didn't really change.
Also, even though I didn't check this, my guess is that there are other ways to get references to stale nodes, like using the back/forward functionality, having a search window open, or adding a manually comment in another tab.
Unfortunately I'm not familiar enough with the codebase propose a better solution :(
Jadx version
master
Java version
25.02
OS
Summary
go-to-definitioncan jump to the wrong line after renaming in another open tab.Reproduction
go-to-definitionon the reference.Expected
The editor jumps to the current declaration position.
Actual
The editor can jump to a stale offset, usually the line that matched before the rename/comment inserted extra lines above the declaration.
Suspected cause
RenameService.refreshState()buildsupdatedTopClassesfromnode.addUpdateNodes(...), which is based on usages of the renamed symbol. Only tabs whose root class appears in that set are refreshed (inRenameService.refreshTabs).That means an open tab that references the renamed symbol may stay on an old
cachedCodeInfoif its class is not included inupdatedTopClasses, even though the code layout changed above the referenced declaration.Other thoughts
My guess is that adding all of the tabs that have a reference to the class, and not just the method/field would fix the issue, but might not be the best because it would refresh classes that didn't really change.
Also, even though I didn't check this, my guess is that there are other ways to get references to stale nodes, like using the
back/forwardfunctionality, having a search window open, or adding a manually comment in another tab.Unfortunately I'm not familiar enough with the codebase propose a better solution :(
Jadx version
master
Java version
25.02
OS