Bugzilla – Full Text Bug Listing
| Summary: | [1.8][search] Find Declarations (Ctrl + G) shows no result for type-less lambda parameter | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Noopur Gupta <noopur_gupta> | ||||||
| Component: | Core | Assignee: | Manoj N Palat <manoj.palat> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | manoj.palat, srikanth_sankaran | ||||||
| Version: | 4.4 | ||||||||
| Target Milestone: | BETA J8 | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
I doubt that this is a JDT/Core problem. Let me check. See that control clicking on the type elided x's usage takes you to the declaration. That shows that selection engine computes the java element correctly. Also the hover links look good. Noopur, please check what API if any is used subsequently after determining the Java element. I suspect a problem in ILocalVariable#getTypeSignature (In reply to Srikanth Sankaran from comment #3) > I suspect a problem in ILocalVariable#getTypeSignature No, this works fine too, Noopur, please triage and send it back to JDT/Core if necessary with clear instructions on which API if something is misbehaving. Without knowing what the client does to hit the dead end, it is difficult to make progress or even conclude JDT/Core is at fault here. Add a breakpoint at org.eclipse.jdt.internal.ui.search.JavaSearchQuery, line: 144 which invokes SearchEngine.search(SearchPattern pattern, SearchParticipant[] participants, IJavaSearchScope scope, SearchRequestor requestor, IProgressMonitor monitor) as:
engine.search(pattern, new SearchParticipant[] { SearchEngine.getDefaultSearchParticipant() }, fPatternData.getScope(), collector, mainSearchPM);
After the call to search engine, the SearchRequestor (collector) does not contain any match for case [1].
The pattern passed to search has resolved type for lambda parameter in both [1] and [2].
Also, note that org.eclipse.jdt.internal.ui.search.NewSearchResultCollector.acceptSearchMatch(SearchMatch match) is not hit during debugging for case [1], whereas it is hit with a SearchMatch for case [2].
Hence, it looks like an issue in SearchEngine#search.
Thanks Noopur, Manoj, please work on this, Thanks. I think I know the problem. For type elided parameter declarations index entries should be created after resolve and not before resolve. Manoj, see if this is the problem. Created attachment 240592 [details]
Proposed Patch
Issue was that MatchLocatorParser() did not override consumeTypeElidedLambdaParameter() and hence the match did not happen. Fixed with the patch attached above.
This patch does not apply :( Manoj, it looks like you posted the wrong patch - this is already released I went and created a fix and test (Manoj already had discussed the outline of the fix) Something has horribly gone wrong during the commit - I don't see the main fix but see fragments - studying what went wrong ... Created attachment 240596 [details]
Proposed Patch
correct patch attached. Thanks Srikanth.
Fix here: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=c2d0f99b1b05ac2833cefa5e25e72d4b3b457443 Tests hooked up here: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?h=BETA_JAVA8&id=c9149a9e01b5270f227b43ea4becd111429960bf Verified as working for Eclipse + Java 8 RC2 using Kepler SR1 + Eclipse Java Development Tools Patch for Java 8 Support (BETA) 1.0.0.v20140306-1935 |
package one.test; @FunctionalInterface interface Foo { int foo(int x); } public class T { // Select 'x' in lambda body and press Ctrl+G. Foo f1= x -> x; //[1] Foo f2= (int x) -> x; //[2] } ----------------------------------------------------- - Select 'x' in lambda body. - Go to the menu: Search > Declarations > Workspace. Or, press Ctrl+G. - Works at [2] but shows no result at [1].