Summary: | "Find Unused Dependencies" misses field/method references if type is never named | ||
---|---|---|---|
Product: | [Eclipse Project] PDE | Reporter: | Matt McCutchen <hashproduct+eclipse> |
Component: | UI | Assignee: | PDE-UI-Inbox <pde-ui-inbox> |
Status: | RESOLVED WONTFIX | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | frederic_fusier, philippe_mulet |
Version: | 3.2 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: |
Description
Matt McCutchen
2006-04-09 21:55:34 EDT
We need Frederic's input on this one... I'm not sure it would be feasible. Your request sounds like an additional storage in search indexes, but to be able to do it, these kind of references need resolution. In your example, compiler needs to resolve the expression Bar.myFoo.x (I guess myFoo field is static otherwise the code is not correct...) to know that myFoo is a field of Foo class. Without resolving, myFoo is just a name reference nothing else and currently indexer does not store anything for this. The problem is that resolution during indexing is forbidden as it would take too much time. So, I'm afraid we can't apply your suggestion and if PDE absolutely needs to find this kind of dependencies, it has to perform real search requests as searchDeclarationsOfAccessedFields and searchDeclarationsOfSentMessages... thanks Frederic. resolving to later as I don't see us doing anything of the sort in the near future. (In reply to comment #2) > I'm not sure it would be feasible. Your request sounds like an additional > storage in search indexes, but to be able to do it, these kind of references > need resolution. True, a new index would be needed to make the search for field and method references efficient. I was proposing a simpler technique: the PDE could do an individual search for references on each field and method defined by each type in each dependency. However, since there are so many fields and methods, I'm guessing the fix would make "Find unused dependencies" take 10 times as long or even longer. What do you think about having the Java builder note dependencies as it encounters them? Is this too much work to consider for 3.3? This isn't a search issue I think. The Java builder already deals with such dependencies. Either we'd expose the build state internals, or we would take over the problem of finding unused entries on the build path. I would rather envisage the latter at this point. Then PDE would need to leverage this in term of plugin dependencies. We already have a request for this in JDT/Core. Frederic - can you pls add a pointer to it ? As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you. |