Comment 1 Jerome Lanneluc 2008-06-18 02:40:01 EDT

David, isn't it a dup of a bug you worked on recently?

Comment 2 Ketan Padegaonkar 2008-06-18 04:33:38 EDT

To get rid of this particular problem, I knocked off .metadata, reinstalled eclipse.

The only addition plugins I have in my eclipse installation are subversive, mylyn.

The problem still continues, and autocomplete is broken *completely* by not being able to make autocomplete selections, although the autocomplete list does pop up.

What is surprising is that this issue started without me changing any configuration in my eclipse.

Is there any workaround for this ?

Comment 3 Philipe Mulet 2008-06-18 06:15:52 EDT

Ketan - Can you provide steps to reproduce ?

Comment 4 Ketan Padegaonkar 2008-06-18 06:31:42 EDT

I created a fresh workspace with a java project containing the following class. I'm able to view and complete methods on the fooBar instance inside the doSomething() method.

package a.b.c;

public class FooBar {
	FooBar fooBar = new FooBar();
	public void doSomething() {
				
	}
}

However checking out the source code to my application in this *same* workspace fails to do autocompletes.

I'm not sure how you can reproduce this, but if there's any more information, logs, etc. that you need, I'll be more than happy to provide it.

Comment 5 Philipe Mulet 2008-06-18 06:48:17 EDT

Could you share your application source ? Or if confidential (as I would expect), can you provide a reduced version of it, just enough to reproduce the problem ?

Comment 6 Ketan Padegaonkar 2008-06-18 07:06:48 EDT

I would not be able to share the entire code base, I'll try to isolate it to a couple of classes in a plugin and attach it to this bug.

Comment 7 Ketan Padegaonkar 2008-06-18 08:22:24 EDT

Here's what I found out:

There was a missing dependency in the class that I was auto completing inside: "The type org.eclipse.core.resources.IProject cannot be resolved. It is indirectly referenced from required .class files"

Adding o.e.core.resources to the project dependency has fixed autocompletes for me.

Comment 8 Philipe Mulet 2008-06-18 09:04:47 EDT

Good, still the tooling should be resilient to this kind of mistake, i.e. we are still interested by a reduced testcase.

Comment 9 Philipe Mulet 2008-06-18 09:33:03 EDT

Scanning the trace, I believe there are 2 problems:

1. #availableFields() should be more resilient in general (not just for BinaryTypeBinding). Same for #availableMethods(). This is more of a 3.5 item.
I entered bug 237623 for it

2. in order for the unresolvable type to not cause the abort, the completion context should protect its entry points to ensure a referenceContext is set properly before causing more resolution. This is similar to the problem mentionned by Jerome in comment 1, but a different code path.
This one should be addressed for 3.4.1 I think.

org.eclipse.jdt.internal.codeassist.InternalExtendedCompletionContext.searchVisibleFields(InternalExtendedCompletionContext.java:491)

Comment 10 Ketan Padegaonkar 2008-06-18 09:51:23 EDT

Created attachment 105288 [details]
Test project to reproduce error

A project where:
Foobar contains some API that's invoked in foobarTest
FoobarTestBase depends on jdt.core, core.resources
FoobarTest depends on the above projects in addition to jdt.core and junit


Steps to reproduce:
1. Open SeleniumClasspathContainerInitializerTest#testCreatesClasspathEntries, and type in "initializer" to autocomplete. Autocomplete does not work.
2. Add o.e.core.resources to FoobarTest and autocomplete, autocomplete works.

Comment 11 David Audel 2008-06-19 07:41:52 EDT

When i use the test case of comment 10 the completion fails due to an internal exception

Exception caught by CompletionEngine:
org.eclipse.jdt.internal.compiler.problem.AbortCompilation
	at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:121)
	at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:179)
	at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.handle(ProblemReporter.java:1830)
	at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.isClassPathCorrect(ProblemReporter.java:3702)
	at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:54)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:101)
	at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:168)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:456)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:510)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveSingleImport(CompilationUnitScope.java:713)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage(Scope.java:2443)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.getType(Scope.java:2184)
	at org.eclipse.jdt.internal.compiler.ast.SingleTypeReference.getTypeBinding(SingleTypeReference.java:44)
	at org.eclipse.jdt.internal.compiler.ast.TypeReference.internalResolveType(TypeReference.java:130)
	at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType(TypeReference.java:197)
	at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.resolveTypeFor(SourceTypeBinding.java:1297)
	at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.fields(SourceTypeBinding.java:616)
	at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.availableFields(ReferenceBinding.java:167)
	at org.eclipse.jdt.internal.codeassist.CompletionEngine.computeAlreadyDefinedName(CompletionEngine.java:9341)
	at org.eclipse.jdt.internal.codeassist.CompletionEngine.computeAlreadyDefinedName(CompletionEngine.java:9292)
	at org.eclipse.jdt.internal.codeassist.CompletionEngine.complete(CompletionEngine.java:1126)
	at org.eclipse.jdt.internal.codeassist.CompletionEngine.complete(CompletionEngine.java:2554)
	at org.eclipse.jdt.internal.core.Openable.codeComplete(Openable.java:129)



But if i type 'Object o; o.equa' instead of 'initializer' then i reproduce the same exception.

org.eclipse.jdt.internal.compiler.problem.AbortCompilation
	at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:121)
	at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:179)
	at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.handle(ProblemReporter.java:1830)
	at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.isClassPathCorrect(ProblemReporter.java:3702)
	at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:54)
	at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:101)
	at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:168)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:456)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:510)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveSingleImport(CompilationUnitScope.java:713)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage(Scope.java:2443)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.getType(Scope.java:2184)
	at org.eclipse.jdt.internal.compiler.ast.SingleTypeReference.getTypeBinding(SingleTypeReference.java:44)
	at org.eclipse.jdt.internal.compiler.ast.TypeReference.internalResolveType(TypeReference.java:130)
	at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType(TypeReference.java:197)
	at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.resolveTypeFor(SourceTypeBinding.java:1297)
	at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.fields(SourceTypeBinding.java:616)
	at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.availableFields(ReferenceBinding.java:167)
	at org.eclipse.jdt.internal.codeassist.InternalExtendedCompletionContext.searchVisibleFields(InternalExtendedCompletionContext.java:493)
	at org.eclipse.jdt.internal.codeassist.InternalExtendedCompletionContext.searchVisibleVariablesAndMethods(InternalExtendedCompletionContext.java:763)
	at org.eclipse.jdt.internal.codeassist.InternalExtendedCompletionContext.computeVisibleElementBindings(InternalExtendedCompletionContext.java:177)
	at org.eclipse.jdt.internal.codeassist.InternalExtendedCompletionContext.getVisibleElements(InternalExtendedCompletionContext.java:354)
	at org.eclipse.jdt.core.CompletionContext.getVisibleElements(CompletionContext.java:327)
	at org.eclipse.jdt.internal.ui.text.java.ParameterGuessingProposal.getAssignableElements(ParameterGuessingProposal.java:109)
	at org.eclipse.jdt.internal.ui.text.java.ParameterGuessingProposal.guessParameters(ParameterGuessingProposal.java:289)



The fix for bug 101610 fix the problem with 'initializer' and we should add a similar fix in InternalExtendedCompletionContext#computeVisibleElementBindings() to fix the the problem with 'o.equa'.

Comment 12 Philipe Mulet 2008-06-19 10:10:02 EDT

Clarification re: comment 11
>> When i use the test case of comment 10 the completion fails due to an internal
exception
This one will be taken care of by fix for bug 101610

Comment 13 David Audel 2008-07-15 07:05:42 EDT

Created attachment 107442 [details]
Proposed fix

Comment 14 David Audel 2008-07-15 07:08:06 EDT

Released for 3.5M1.

Tests added
  CompletionTests2#testBug237469a() -> testBug237469b()

Comment 15 David Audel 2008-07-15 07:11:58 EDT

Created attachment 107443 [details]
Proposed fix for 3.4.1

To avoid the exception this.lookupEnvironment.unitBeingCompleted must be set
to the compilation unit which contains the completion node when the completion context compute the list of visible elements.

Comment 16 David Audel 2008-07-15 07:21:46 EDT

This bug is not a regression because the completion context compute visible elements only since 3.4.

The fix is simple and not risky. The fix avoid that code assist fail when the classpath of a project is incomplete.

Philippe - Do you approve this fix for 3.4.1 ?

Comment 17 Philipe Mulet 2008-07-16 06:00:34 EDT

+1 for 3.4.1

Comment 18 David Audel 2008-07-16 06:08:48 EDT

Released for 3.4.1.

Tests added
  CompletionTests2#testBug237469a() -> testBug237469b()

Comment 19 Olivier Thomann 2008-08-06 12:14:44 EDT

Verified for 3.5M1 using I20080805-1307

Comment 20 Olivier Thomann 2008-08-06 12:39:26 EDT

Closing as FIXED to be closed as VERIFIED during 3.4.1 verification pass.

Comment 21 Olivier Thomann 2008-08-06 13:13:02 EDT

Reopen to close as RESOLVED/FIXED. Will be closed as VERIFIED during 3.4.1
verification pass.

Comment 22 Olivier Thomann 2008-08-06 13:13:38 EDT

Fixed.

Comment 23 Ketan Padegaonkar 2008-08-06 14:37:33 EDT

Thanks for the fix :)

Comment 24 Frederic Fusier 2008-08-29 03:45:10 EDT

Verified for 3.4.1 using M20080827-2000.