Summary: | Missing library classes kill Intellisense without Error | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Sam Hendley <sam.hendley> | ||||||||
Component: | Core | Assignee: | Kent Johnson <kent_johnson> | ||||||||
Status: | RESOLVED FIXED | QA Contact: | |||||||||
Severity: | normal | ||||||||||
Priority: | P3 | CC: | daniel_megert, james.synge, jerome_lanneluc, kent_johnson, philippe_mulet | ||||||||
Version: | 3.2.1 | ||||||||||
Target Milestone: | 3.3 M6 | ||||||||||
Hardware: | PC | ||||||||||
OS: | Windows XP | ||||||||||
Whiteboard: | |||||||||||
Attachments: |
|
Description
Sam Hendley
2007-03-01 18:26:14 EST
Created attachment 60122 [details]
TestCase
Comments in Test.java should show the issues
Looks like a duplicate of bug 164266. Kent - shouldn't this be supported using our missing binary type support ? Just an update, there is an error log if the missing classes are directly related to the current class. I was seeing some "Java model errors" for a class I was extended over. The situation in this case the missing classes were inner classes of Screen. When I tried to do the intellisense I would get two error messages for these two missing classes. It was what I was hoping could be done in the other situation as it made patching the library much easier. Thanks. class A extends Screen{} lib: class Screen{ class innerClass1{} class innerClass2{} class missingClass1{} class missingClass2{} } Philippe - our missing binary type support doesn't kick in, because the referenced types are found as source types & not binary types. We would need to change the o.e.jdt.internal.core.SearchableEnvironment & NameLookup to find binary types instead of source types for any referenced types that are not currently being modified in working copies. I do find it odd that the PackageFragment for a package in a prereq project is picked up a source package & not a binary package. Jerome - Can o.e.jdt.internal.core.SearchableEnvironment & NameLookup find binary types instead of source types in cases like this one ? (In reply to comment #6) > Jerome - Can o.e.jdt.internal.core.SearchableEnvironment & NameLookup find > binary types instead of source types in cases like this one ? > Note this comment applies to bug 164266. Moving this comment there. For this sepcific bug, I'm getting which might explain the silent failure. (Kent back to you.) !ENTRY org.eclipse.jdt.core 4 4 2007-03-20 19:09:48.806 !MESSAGE Could not retrieve declared methods !STACK 0 org.eclipse.jdt.internal.compiler.problem.AbortCompilation at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:97) at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:153) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.handle(ProblemReporter.java:1727) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.isClassPathCorrect(ProblemReporter.java:3520) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.cacheMissingBinaryType(LookupEnvironment.java:178) at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:46) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:131) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveTypesFor(BinaryTypeBinding.java:893) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.methods(BinaryTypeBinding.java:874) at org.eclipse.jdt.core.dom.TypeBinding.getDeclaredMethods(TypeBinding.java:266) at org.eclipse.jdt.internal.corext.dom.Bindings.findOverriddenMethodInType(Bindings.java:423) at org.eclipse.jdt.internal.corext.dom.Bindings.findOverriddenMethodInHierarchy(Bindings.java:440) at org.eclipse.jdt.internal.corext.dom.Bindings.findOverriddenMethod(Bindings.java:483) at org.eclipse.jdt.internal.ui.javaeditor.OverrideIndicatorManager$1.visit(OverrideIndicatorManager.java:179) at org.eclipse.jdt.core.dom.MethodDeclaration.accept0(MethodDeclaration.java:486) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2476) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2546) at org.eclipse.jdt.core.dom.TypeDeclaration.accept0(TypeDeclaration.java:483) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2476) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2546) at org.eclipse.jdt.core.dom.CompilationUnit.accept0(CompilationUnit.java:213) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2476) at org.eclipse.jdt.internal.ui.javaeditor.OverrideIndicatorManager.updateAnnotations(OverrideIndicatorManager.java:172) at org.eclipse.jdt.internal.ui.javaeditor.OverrideIndicatorManager.reconciled(OverrideIndicatorManager.java:251) at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.reconciled(CompilationUnitEditor.java:1572) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:137) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.initialReconcile(JavaReconcilingStrategy.java:176) at org.eclipse.jdt.internal.ui.text.CompositeReconcilingStrategy.initialReconcile(CompositeReconcilingStrategy.java:114) at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.initialReconcile(JavaCompositeReconcilingStrategy.java:122) at org.eclipse.jface.text.reconciler.MonoReconciler.initialProcess(MonoReconciler.java:103) at org.eclipse.jdt.internal.ui.text.JavaReconciler.initialProcess(JavaReconciler.java:332) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:170) Sam, to clarify: the code assist (what you call intellisense) failing silently is fixed in the 3.3 stream. However the "Add uninplemented methods" silent failure is still present in the 3.3 stream and is due to the stack trace I just reported. The exception is thrown because there is no referenceContext for the ProblemHandler. The ProblemHandler's referenceContext comes from the LookupEnvironment's unitBeingCompleted. We null out the LookupEnvironment's unitBeingCompleted at the end of Compiler.resolve(), which is called during the reconcile loop. We need to leave it set to the last unit since the binary types can be accessed thru the dom afterwards. Created attachment 61447 [details]
Proposed patch
Do we want to release this change for M6 or wait for M7?
Created attachment 61459 [details] Patch for tests Need to fixup expected results for bug 173338 ASTConverter15Test test0239() & test0240() I think the fix is good. If we recontribute for M6, and tests are fine, then I would put it in. Released to HEAD Adding missing comment to have this bug in our verification list: Released for 3.3 M6 Kent could you please backport this fix in R3_2_maintenance ? Backported to R3_2_maintenance *** Bug 183508 has been marked as a duplicate of this bug. *** |