Community
Participate
Working Groups
package bug; import org.eclipse.swt.widgets.Text; class T2 { Text text = new Text(null, 0); private void bar() { text.setSelection(0); } } -------------------------------------------------- Place the caret at #setSelection in the above example and press Ctrl+T. The resulting quick type hierarchy pop-up is empty. Place caret at "Text" and press F4. Type Hierarchy view shows only "Object". This used to work before Java 8 related code changes (up to I20140311-1200).
This is a must fix. If I open only Text (as binary), the hierarchy is fine. As soon as I open the source which refers to Text, e.g. T2 from comment 2, it is broken, even if the hierarchy is requested in the editor for Text.class.
The problem seems to be in org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver with the changes in commit 76226936180e26d9e682e909ba765fff61d327d9. When the change in HierarchyResolver at line 684 is reverted back from: containsLocalType = cu.isWorkingCopy() ? true /* presume conservatively */ : localTypes.contains(path.toString()); to: containsLocalType = localTypes.contains(path.toString()); the issue does not happen anymore.
(In reply to Noopur Gupta from comment #2) > The problem seems to be in > org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver with the changes > in commit 76226936180e26d9e682e909ba765fff61d327d9. > > When the change in HierarchyResolver at line 684 is reverted back from: > > containsLocalType = cu.isWorkingCopy() ? true /* presume conservatively */ : > localTypes.contains(path.toString()); > > to: > > containsLocalType = localTypes.contains(path.toString()); > > the issue does not happen anymore. Thanks so much Noopur for narrowing down on the commit. As for the original fix, the variable containsLocalType (whose value is assumed to true if/when the CU is working copy) has far reaching impact. It is used not just for setting the LOCAL_TYPE flag while building CU, but it is also stored and used further down the method including for completing bindings. I will look at this.
Created attachment 243750 [details] Proposed fix Here's what's going: The commit Nooper mentioned forces the fields and method bodies of type T2 (example in comment #0) to be parsed. This forces two things: 1. The type org.eclipse.swt.widgets.Text to be resolved and cached [1] 2. The superclass of Text is set (but the sub types are not yet computed) [2] [2] happens via this call stack [3]: BinaryTypeBinding.cachePartsFrom(...) line: 435 LookupEnvironment.createBinaryTypeFrom(...) line: 695 LookupEnvironment.cacheBinaryType(...) line: 213 HierarchyResolver.resolve(...) line: 755 IndexBasedHierarchyBuilder.buildForProject(...) line: 227 IndexBasedHierarchyBuilder.buildFromPotentialSubtypes(...) line: 344 [1] means, the following condition [4] at line no 843 in HierarchyResolver fails: if (focusBinaryBinding == null) return; And because of that, we go ahead and report the incomplete hierarchy for Text. Later when the call returns to IndexBasedHierarchyBuilder.buildFromPotentialSubtypes(...), we check for the type to be in the hierarchy (line no: 335). The following condition fails, due to which we don't proceed with the buildForProject() call (line no: 344) if (!this.hierarchy.contains(focusType)) {...} And that's how we end up with incomplete hierarchy. The solution: simply enhance the condition [4] with the check for TagBits.HasUnresolvedSuperclass, which would have been set at [4]. Question: Why do we need this special treatnment for lambdas and not for anonymous? Ans: I think it's because the SourceElementNotifier and CompilationUnitStructureRequester together ensure full parse happens and cached in Java model when there are local types. This will be a worthwhile exercise post Luna to make similar things for Lambda. With this fix, all JDT Core and UI tests pass. I will add a new test for this case.
Created attachment 243756 [details] Same patch with test Test added to the fix
(In reply to Jayaprakash Arthanareeswaran from comment #4) > Question: Why do we need this special treatnment for lambdas and not for > anonymous? > Ans: I think it's because the SourceElementNotifier and > CompilationUnitStructureRequester together ensure full parse happens and > cached in Java model when there are local types. This will be a worthwhile > exercise post Luna to make similar things for Lambda. > > With this fix, all JDT Core and UI tests pass. I will add a new test for > this case. Looks reasonable to me.
(In reply to Jayaprakash Arthanareeswaran from comment #5) > Created attachment 243756 [details] > Same patch with test This passes all JDT Core and UI tests. To further add a word about the patch as to why this is safe: The presence of bit TagBits.HasUnresolvedSuperclass means the type was resolved but not fully processed for type hierarchy as I mentioned in comment #4. In certain cases (like the one we are dealing with here), a type can have it's hierarchy partially set, such as only it's super types computed but not sub types. At this point, we should delay reporting it's hierarchy. Looking at IndexBasedHierarchyBuilder.buildFromPotentialSubtypes(), line no: 335, it is guaranteed that buildForProject() is called one more time which will ensure that the complete hierarchy will be reported. This fix also ensures that the commit that is mentioned in comment #2 is left untouched, which means we continue to report local types in the hierarchy.
+1 for RC4. The patch also fixes problems with this field declaration in a working copy: org.eclipse.swt.custom.MovementListener mListener = null; Without the patch, the supertype hierarchy for interface MovementListener contained SWTEventListener as super*class*. With the patch, everything is fine.
Released comment 5 as http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=fa1b4dd537bd7a82cd2ae8dc7ab09a5696b58180
Verified in I20140603-2300.
*** Bug 439093 has been marked as a duplicate of this bug. ***
