Comments (2)
This os one I hate most. Especially on methods named run(), getName() etc call hierarchy usually shows too many false matches.
from eclipse.jdt.core.
Checking with simplified snippet:
public class CallHiearchyTest {
public static interface Action1 {
public void doit();
}
public static interface Action2 {
public void doit();
}
public static void action1( Action1 action ) {
action.doit();
}
public static void action2( Action2 action ) {
action.doit();
}
public static void test22() {
action2( new Action2() {
public void doit() { // call hierarchy here
System.out.println( "Bar" );
}
} );
}
}
Call hierarchyt on Action2.doit()
shows only test22()
. So the call hierarchy doesn't seem to concern itself with the case of calling action1(Action1)
with an instance of e.g. Sub implements Action1, Action2
. Also replacing interface
with abstract class
results in the same unexpected contents under callers
.
The accurate matches for calls which should not be on the call hierarchy are computed with this stack trace:
"Worker-35: Fetching children of doit" #384 prio=5 os_prio=0 cpu=319.35ms elapsed=2748.66s tid=0x00007f30dc068790 nid=0x49b5 runnable [0x00007f30c7cfd000]
java.lang.Thread.State: RUNNABLE
at org.eclipse.jdt.internal.core.search.matching.PatternLocator.resolveLevelForType(PatternLocator.java:830)
at org.eclipse.jdt.internal.core.search.matching.PatternLocator.resolveLevelForType(PatternLocator.java:754)
at org.eclipse.jdt.internal.core.search.matching.MethodLocator.resolveLevelAsSubtype(MethodLocator.java:871)
at org.eclipse.jdt.internal.core.search.matching.MethodLocator.resolveLevel(MethodLocator.java:800)
at org.eclipse.jdt.internal.core.search.matching.MethodLocator.resolveLevel(MethodLocator.java:718)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:2807)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.process(MatchLocator.java:2046)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1362)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1399)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1541)
at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:135)
at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:251)
at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:602)
at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:670)
at org.eclipse.jdt.internal.corext.callhierarchy.CallerMethodWrapper.findChildren(CallerMethodWrapper.java:155)
at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.performSearch(MethodWrapper.java:266)
at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.doFindChildren(MethodWrapper.java:197)
at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.getCalls(MethodWrapper.java:88)
at org.eclipse.jdt.internal.ui.callhierarchy.DeferredMethodWrapper.getCalls(DeferredMethodWrapper.java:70)
at org.eclipse.jdt.internal.ui.callhierarchy.DeferredMethodWrapper.fetchDeferredChildren(DeferredMethodWrapper.java:78)
at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:219)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Here fullyQualifiedName
is eclipse.CallHiearchyTest.Action1
and qualifiedPattern
is eclipse.CallHiearchyTest.*
(and so there is an accurate match). The pattern is coming from here:
"Worker-39: Fetching children of doit" #399 prio=5 os_prio=0 cpu=4.20ms elapsed=333.90s tid=0x00007f30c02fbdb0 nid=0x6213 runnable [0x00007f30c72fe000]
java.lang.Thread.State: RUNNABLE
at org.eclipse.jdt.core.search.SearchPattern.createPattern(SearchPattern.java:2156)
at org.eclipse.jdt.internal.corext.callhierarchy.CallerMethodWrapper.findChildren(CallerMethodWrapper.java:144)
at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.performSearch(MethodWrapper.java:266)
at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.doFindChildren(MethodWrapper.java:197)
at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.getCalls(MethodWrapper.java:88)
at org.eclipse.jdt.internal.ui.callhierarchy.DeferredMethodWrapper.getCalls(DeferredMethodWrapper.java:70)
at org.eclipse.jdt.internal.ui.callhierarchy.DeferredMethodWrapper.fetchDeferredChildren(DeferredMethodWrapper.java:78)
at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:219)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Computed with this code:
char[][] enclosingNames = enclosingTypeNames(declaringClass);
if (enclosingNames.length > 0) {
declaringQualification = CharOperation.concat(declaringQualification, CharOperation.concatWith(enclosingNames, '.'), '.');
}
from eclipse.jdt.core.
Related Issues (20)
- [Patterns][records] ECJ fails to generate code to deconstruct record in pattern
- [Patterns] Design smell: Pattern classes are far from object oriented
- IllegalArgumentException using newer batch compiler with ast parser HOT 5
- Migration of JDT wiki pages HOT 2
- Missing resource leak warning for FileInputStream HOT 1
- [Sealed classes] Incorrect Reconciler error: The type A that implements a sealed interface I should be a permitted subtype of I
- [Patterns][records] Instanceof with record deconstruction patterns should never be flagged as unnecessary
- [Patterns][records] ECJ fails to reject incompatible pattern types.
- Code format HOT 2
- ECJ produces redundant bytecode for instanceof pattern matching HOT 3
- [Patterns] ECJ generates suspect code for switching over patterns
- IrritantSet needs unsigned right shift for GROUP4 and higher HOT 4
- [Patterns][records][inference] ECJ never computes the upwards projection for var type inference in record patterns HOT 3
- [Patterns][unnamed] Support for identifier '_' for old compile source/target versions HOT 2
- [Patterns][internal] toString() output of AST nodes shows up with modifier sealed for pattern variables
- [Switch][Pattern] Withdraw the internal AST APIs Pattern.suspendVariables & Pattern.resumeVariables
- [Patterns][Unnamed] Wasteful allocation and assignment into unnamed pattern variables.
- [Patterns][internal] High degree of code duplication in instanceof pattern code generation
- [Patterns][Unnamed] VerifyError with unnamed pattern variable in instanceof HOT 1
- CommentRecorderParser sometimes generates ranges that miss Javadoc HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from eclipse.jdt.core.