Community
Participate
Working Groups
I have this source code: if( InputFieldType.MULTIPLE_LINE_TEXT == getInputFieldType() ) { postProcessMultiLineText(); } return options; } private void postProcessMultiLineText() { // TODO Auto-generated method stub } When the cursor is on the first "postProcessMultiLineText()" and I press F3, Eclipse says "Current text selection cannot be opened in an editor" in the status bar. Ctrl+Click doesn't work. Actually, both ways to navigate to the declaration doesn't work in most places in the file, not even for things like String. The outline works and Ctrl+Shift+T also still works. It also still works in other Java editors in the same project. It's just a single editor that it affected. So my guess is that some cache which Eclipse uses to do this navigation got corrupted in a way that neither - Opening the class again - Restarting Eclipse - Cleaning the project - Close&Open the project fixes this. I've seen similar problems with the .markers file which can accumulate garbage in Xtext editors. The only way to get rid of it is to close the project, delete the marker file, open the project and force a rebuild. To debug this further, I'd like to know where in Eclipse's code I could set breakpoints to find out why it can't locate the types anymore. Alternatively: Which per-editor files in .metadata should contain this navigation info? How can I force Eclipse to rebuild them?
Do you see an exception in the Error Log or .metadata or .log files?
Nothing that seems related. My guess is that Eclipse believes that the cache is still OK and doesn't need updating. What still works is clicking on "break" and "continue"; that will get me to the related loop. But all Java type lookup is broken in this file. In another file in the same package of the project, everything works fine. When I grep the .metadata folder for the class, I get these results: /work/workspace/.metadata/.plugins/org.eclipse.jdt.ui/QualifiedTypeNameHistory.xml /work/workspace/.metadata/.plugins/org.eclipse.jdt.ui/OpenTypeHistory.xml /work/workspace/.metadata/.plugins/org.eclipse.debug.ui/launchConfigurationHistory.xml /work/workspace/.metadata/.plugins/org.eclipse.e4.workbench/workbench.xmi /work/workspace/.metadata/.plugins/org.eclipse.core.resources/.snap /work/workspace/.metadata/.plugins/org.eclipse.core.resources/.root/61.tree /work/workspace/.metadata/.plugins/org.eclipse.core.resources/.history/c5/50a66cb565ab00131995b80345616221 /work/workspace/.metadata/.plugins/org.eclipse.core.resources/.projects/blu-core/.markers /work/workspace/.metadata/.plugins/org.eclipse.ltk.core.refactoring/.refactorings/blu-core/2014/3/12/refactorings.history /work/workspace/.metadata/.plugins/org.eclipse.jdt.junit.core/history/20140318-161850.446.xml /work/workspace/.metadata/.plugins/org.eclipse.jdt.core/1307505951.index /work/workspace/.metadata/.plugins/org.eclipse.jdt.core/3735228071.index Which of these is used for "Open Declaration"?
If it still doesn't work after all the steps you listed, then I don't think a cache is the problem. It sounds like the compiler has a serious problem with building an AST for this file and doesn't even get to the stage where it tries to resolve a type. Could you try to remove parts of the affected file and maybe even come up with a self-contained snippet to reproduce the problem? F3 and Ctrl+Click use org.eclipse.jdt.internal.core.CompilationUnit#codeSelect(..) to compute the target.
Thanks. I'll try to run Eclipse in the debugger to see what happens.
Okay, I think I found the problem: When I step through the code, I get this exception in org.eclipse.jdt.internal.codeassist.SelectionEngine.select(ICompilationUnit, int, int): org.eclipse.jdt.internal.compiler.problem.AbortCompilation: Pb(324) The type com.pany.X$Y cannot be resolved. It is indirectly referenced from required .class files at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:135) at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:201) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.handle(ProblemReporter.java:2176) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.isClassPathCorrect(ProblemReporter.java:4211) There is nothing in the error log because the exception is swallowed (line 973 in org.eclipse.jdt.internal.codeassist.SelectionEngine.select(ICompilationUnit, int, int): } catch (AbortCompilation e) { // ignore this exception for now since it typically means we cannot find java.lang.Object if(DEBUG) { System.out.println("Exception caught by SelectionEngine:"); //$NON-NLS-1$ e.printStackTrace(System.out); } } :-( Interestingly, the CompilationResult further up in the code says: Filename : /.../com/pany/Foo.java COMPILED type(s) No PROBLEM So I tried to find out where the error comes from which led me to a third type Bar. What I see in the code is this pattern: I have Foo.java and I try to look up anything in there. One of the imports in Foo.java is Bar. That import comes from a JAR which is on the classpath. Bar, in turn imports X$Y from X.java. So Foo.java comes from project A which is open. Project B contains X.java and is open as well. The lookup is project A -> JAR -> project B and something in that chain fails. This is the call stack when this happens: SelectionEngine$3(ProblemHandler).handle(int, String[], int, String[], int, int, int, ReferenceContext, CompilationResult) line: 135 SelectionEngine$3(ProblemHandler).handle(int, String[], String[], int, int, ReferenceContext, CompilationResult) line: 201 SelectionEngine$3(ProblemReporter).handle(int, String[], String[], int, int) line: 2176 SelectionEngine$3(ProblemReporter).isClassPathCorrect(char[][], CompilationUnitDeclaration, Object) line: 4211 UnresolvedReferenceBinding.resolve(LookupEnvironment, boolean) line: 59 BinaryTypeBinding.resolveType(TypeBinding, LookupEnvironment, boolean) line: 133 LookupEnvironment.getTypeFromTypeSignature(SignatureWrapper, TypeVariableBinding[], ReferenceBinding, char[][][]) line: 1359 BinaryTypeBinding.createFields(IBinaryField[], long, char[][][]) line: 419 BinaryTypeBinding.cachePartsFrom(IBinaryType, boolean) line: 376 LookupEnvironment.createBinaryTypeFrom(IBinaryType, PackageBinding, boolean, AccessRestriction) line: 700 Just for fun, I added this import at the top of Foo.java: import com.pany.X.Y; When I press F3 on the this import, it works! Also, I don't get compile errors, so the file is definitely there. My guess is that the problem is the transit from Bar.class to X.java on the classpath: Eclipse can compile this but when looking for a type in a JAR, it can't find them in open projects on the classpath. Is that possible?
I tried to create a simplified test case for my situation but CompilationUnit#codeSelect() works in that case. Any pointers how I can debug why Eclipse returns org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding for X$Y?
Two more comments: 1. Replacing the JAR with the actual project on the classpath solves the issue. 2. I'm using Maven and it's org.eclipse.m2e.MAVEN2_CLASSPATH_CONTAINER. Maybe this has an influence?
Maybe a dup of bug 73957 (see bug 73957 comment 50 for a summary).
(In reply to Markus Keller from comment #8) > Maybe a dup of bug 73957 (see bug 73957 comment 50 for a summary). Maybe the two are related but this isn't a dup. First of all, I have just one huge Maven project in the workspace, so all projects use the same dependencies (and hence the same JARs). In my case, the missing class is in a util JAR that is included in every module, so JDT should be able to see it, no matter over which path it's searched and every module uses the same version, so in the end, all dependencies point to the same place. Is there a way to see the classpath that Eclispe tries to access the "missing" class?
(In reply to Markus Keller from comment #8) > Maybe a dup of bug 73957 (see bug 73957 comment 50 for a summary). I think the difference is that PDE avoids putting transitive dependencies on the classpath (unless re-exported) whereas m2e (to the best of my knowledge) puts everything on one flat classpath, transitively. So with m2e we should be able to see everything. (In reply to Aaron Digulla from comment #6) > I tried to create a simplified test case for my situation but > CompilationUnit#codeSelect() works in that case. Thanks for trying. I assume you did not include m2e and its classpath container in that test, right? So, if you are able to debug the bug, you might want to chase down the LookupEnvironment (I see it in one of your stack traces, also BinaryTypeBinding stores it in a field), and drill into its nameEnvironment. Inside you should find the equivalent of the resolved classpath currently in use. HTH
(In reply to Stephan Herrmann from comment #10) > (In reply to Aaron Digulla from comment #6) > > I tried to create a simplified test case for my situation but > > CompilationUnit#codeSelect() works in that case. > > Thanks for trying. I assume you did not include m2e and its classpath > container in that test, right? I did. There must be something else. Unfortunately, I've been too busy to spend time on this in the last weeks. I hope to visit this again in three weeks :-P
Created attachment 250256 [details] Stack trace of "rename method" The attachment bug-430605-eclipse-refactoring-error.txt might be related to this bug. I was trying to rename a method in a module of the project but the error was thrown and Eclipse did roll back all changes.
(In reply to Aaron Digulla from comment #12) > Created attachment 250256 [details] > Stack trace of "rename method" > > The attachment bug-430605-eclipse-refactoring-error.txt might be related to > this bug. I was trying to rename a method in a module of the project but the > error was thrown and Eclipse did roll back all changes. What connection do you see? For better searchability, here's the top frame from attachment 250256 [details]: java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.connectTypeHierarchy(CompilationUnitScope.java:386)
Created attachment 254292 [details] Project which demonstrates the behavior
Created attachment 254293 [details] Open and closed projects
I've spent four more hours in the Eclipse debugger today and I was finally able to determine and locate the bug. This happens if you have three projects: - main-module - jar-module - util-module main-module contains a class which references a type from jar-module. The class in jar-module references an inner parameterized type from util-module. In a nutwhell: ---------- main-module: Foo.jar ---------------- import Bar ---------- main-module: Foo.jar ---------------- ---------- jar-module: Bar.java ---------------- import org.eclipse.bugs.bug430605.util.X; public class Bar { public final static X.EqualsTool<Bar> BUG = new X.EqualsTool<Bar>( Bar.class ); } ---------- jar-module: Bar.java ---------------- ---------- util-module: X.java ----------------- public class X { /** We need a parameterized inner type here */ public static class EqualsTool<T> { public EqualsTool( Class<T> type ) {} } ---------- util-module: X.java ----------------- This works when project jar-module is open. When the project is closed and you open Foo.java, then Eclipse is suddenly unable to resolve the type X$EqualsTool while parsing Bar.class My guess is that it needs the type "Bar" to be able to fill the type parameter for "EqualsTool<T>" but it doesn't yet know about this type because it's in the middle of parsing "Bar". Setup of the workspace - Clean Eclipse (Kepler SR2) - Install the Maven plugin m2e (I'm using 1.4.1) - Groovy plugin (2.9.1) - Import the project (see attachment above) - Import all the modules of the project - Compile once with "mvn install" - Close the module "jar-module" (as in the attached image) - Clean all projects - Open the type "Foo" - F3 on "String" or "Bar" -> error in the status bar Ctrl+Click simply doesn't work (you don't get any underlines for anything in the file except fields) It starts to work when "EqualsTool" isn't an inner type or when it's not parameterized. Notes: The tests were done with Kepler SR2 (Build id: 20140224-0627) I have the plugins org.eclipse.m2e (1.4.1) and the Groovy plugin (2.9.1) installed. The Groovy plugin has added some patches to the compiler. As far as I can tell, the patches should have no effect on this bug but I don't have a clean install of Eclipse ATM. The sources for the Groovy plugin can be found at https://github.com/groovy/groovy-eclipse/tree/master/jdt-patch/e43/org.eclipse.jdt.core I zipped the sources in batch/*, compiler/*, codeassisst/* and formatter/* to be able to debug. I was here during debugging when I noticed why Eclipse fails: Thread [ModalContext] (Suspended) UnresolvedReferenceBinding.resolve(LookupEnvironment, boolean) line: 52 BinaryTypeBinding.resolveType(TypeBinding, LookupEnvironment, boolean) line: 138 LookupEnvironment.getTypeFromTypeSignature(SignatureWrapper, TypeVariableBinding[], ReferenceBinding, char[][][]) line: 1369 BinaryTypeBinding.createFields(IBinaryField[], long, char[][][]) line: 424 BinaryTypeBinding.cachePartsFrom(IBinaryType, boolean) line: 381 LookupEnvironment.createBinaryTypeFrom(IBinaryType, PackageBinding, boolean, AccessRestriction) line: 710 LookupEnvironment.createBinaryTypeFrom(IBinaryType, PackageBinding, AccessRestriction) line: 686 SelectionEngine(Engine).accept(IBinaryType, PackageBinding, AccessRestriction) line: 60 LookupEnvironment.askForType(PackageBinding, char[]) line: 151 PackageBinding.getTypeOrPackage(char[]) line: 197 CompilationUnitScope.findImport(char[][], int) line: 563 CompilationUnitScope.findSingleImport(char[][], int, boolean) line: 631 CompilationUnitScope.faultInImports() line: 482 CompilationUnitScope.faultInTypes() line: 536 SelectionEngine.select(ICompilationUnit, int, int) line: 924 CompilationUnit(Openable).codeSelect(ICompilationUnit, int, int, WorkingCopyOwner) line: 162 CompilationUnit.codeSelect(int, int, WorkingCopyOwner) line: 379 CompilationUnit.codeSelect(int, int) line: 373 SelectionConverter.codeResolve(IJavaElement, ITextSelection) line: 273 SelectionConverter$1CodeResolveRunnable.run(IProgressMonitor) line: 257 ModalContext$ModalContextThread.run() line: 121 NameEnvironmentAnswer: accessRestriction = null binaryType = null compilationUnit = null sourceTypes = [1] [Info for class EqualsTool [in X [in X.java [in org.eclipse.bugs.bug430605.util [in src/main/java [in util-module]]]]] Class<T> type EqualsTool(Class<T>) boolean isEquals(Object, Object) boolean doEquals(T, T)] util is closed org.eclipse.jdt.internal.compiler.env.NameEnvironmentAnswer typeName = X$EqualsTool packageName = ...correct... org.eclipse.jdt.internal.core.NameLookup.findType(String, String, boolean, int, boolean, boolean, boolean, IProgressMonitor) typeName = X$EqualsTool packageName = ...correct... partialMatch false acceptFlags 30 considerSecondaryTypes true waitForIndexes false checkRestrictions true monitor null
I can reproduce even on latest Mars. Thanks for the detailed steps. I will take a look.
Sorry, couldn't get to this in time. Will look at it during M2.
Moving out of M2
(In reply to Manoj Palat from comment #19) > Moving out of M2 Out of M3
Assigning to Jay per comment 18 and also to have an owner. Jay: please feel free to reassign.
I remember fixing a similar bug in Neon, but can't find the number now. Aaron, are you in a position to check this with a recent Neon build? Thanks!
Not much hope for M7. Tentatively keeping on 4.6 list.
Unfortunately, I've moved to a new company in the mean time. To verify the solution, you have to use the attachment "Project which demonstrates the behavior".
Sorry, no hope for 4.6. Bulk moving to 4.7.
I do not believe this is a problem with corrupted workspace. I have a reproducable case. After creating a new workspace I got the same problem, then I reinstalled Eclipse 4.6.0 and 4.6.1 with new workspaces and same problem occured. Then I found my colleagues also had the same issue, although it works on Mars installation. In the attached screenshot all the SyncWizard's methods are not understood as Java elements, thus the text-search tooltip whereas Declaration or Reference search does not work.
Created attachment 264947 [details] Reproducable case. (SyncWizard is not being understood as Java) Not a corrupted workspace issue!
Created attachment 264950 [details] Simple change to something that does work Maybe a problem with compiler not resolving return type. Funny enough it works ok if I extract the "boolean" return type as local variable.
(In reply to Per Digre from comment #27) > Created attachment 264947 [details] > Reproducable case. (SyncWizard is not being understood as Java) Great, so you can reproduce the problem Can you please also help *us* to reproduce on our machines? Ideally a self-contained zipped project that exhibits the problem in a fresh workspace. TIA
We have a massive project setup which I would not like to take you through. I am sure I can make a simpler test case. I will come back with it after EclipseCon in Ludwigsburg next week.
Created attachment 264994 [details] code to reproduce This code did it... package eclipse_bug; public class CurrentTextSelectionCannotBeOpened { public abstract class Super { public boolean boolMethod(){return true;} public boolean boolMethod(boolean bool){ return bool;} } public class Super2 extends Super{} public class Sub extends Super2{} Object obj; public boolean somecode(){ obj=new Object(){ public boolean somecode(){ Super2 sup=new Sub(); return sup.boolMethod(); } }; return false; } }
Created attachment 264995 [details] code to reproduce - 2 Here's the one that works fine. Not a big difference!
My team has just hit this bug in 4.6.1. We _think_ that we did not experience it in 4.5.x. Any hope for a fix?
(In reply to Per Digre from comment #32) > Created attachment 264995 [details] > code to reproduce - 2 > > Here's the one that works fine. Not a big difference! I can reproduce. Will take a look.
Still present in Photon Milestone 6 (4.8.0M6)
Bulk move out of 4.8
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
I've opened https://github.com/eclipse-jdt/eclipse.jdt.core/issues/860 for the latter problem reported here (https://bugs.eclipse.org/bugs/show_bug.cgi?id=430605#c31), I don't know if its the same one as reported in: https://bugs.eclipse.org/bugs/show_bug.cgi?id=430605#c16 (I didn't install mvn plug-ins to verify it)
Looking at the reproducer from comment 16 and the reproducer from comment 31, I don't think we have the same bug reported in both comments. I've checked the reproducer from comment 31, the bug is due to an anonymous type assigned to a class field. There is no such code in the reproducer from comment 16.
