Community
Participate
Working Groups
Build ID: I20090313-0100 Downloaded "Eclipse Modeling Tools (includes Incubating components)" from the Eclipse Packaging Project. Steps To Reproduce: 1. Enable: Window > Preferences Java > Editor > Content Assist Enable "Fill method arguments and show guessed arguments" Enable "Insert best guessed arguments" 2. Paste the following code into a source folder: public class Test { void foo(String s) {} void bar() { String myString = null; //foo } } 3. Uncomment the //foo, and hit control-space at the end of that line. 4. JDT will insert: (s); and not: (myString);
Your example works for me using plain Eclipse SDK 3.5 M6 and I20090331-0901. Maybe one of the additional plug-ins modifies content assist (I know Mylyn does).
.
I have the same problem with Eclipse 3.5 RC1. I am using mylyn however even when I disable the current task it always uses the parameter name for the auto complete instead of guessing based on type.
> I am using mylyn Exactly my point ;-)
Created attachment 137660 [details] content assist -> advanced -> disable task focused proposal Dani is correct disabled the task focused proposal causes the correct suggestion to be selected. At any rate this is a bug is it not? If not for jdt then for mylyn.
I can reproduce that with the latest Java package but not when running in debug mode. Will investigate further in the next release cycle.
Here is what I have found out: The "Java Proposals (Task-Focused)" category provided by Mylyn will actually return the right proposal when the "Template Proposals" provider is disabled. Enabling the template proposals causes the context that is checked in ParameterGuessingProposal.createProposal() to not have the extended flag set. The reason that the same bug does not occur when the default JDT "Java Proposals" categories is enabled seems to be due to the fact that CompletionProposalComputerRegistry.reload() always reads the JDT categories first. When the default configuration is enabled this causes the Java Proposals computer to run before the Template Proposals whereas the Mylyn Task-Focused Proposals are always run after the Template Proposals. I don't understand the data flow of the JavaContentAssistInvocationContext object that is passed around well enough to propose a fix. Dani, do you have any ideas how to move forward here?
Sorry for the delay Steffen, I was pretty busy lately. I've looked at the code and you are right there's an issue on the framework side as it does not ask all participating completion proposal computers to configure the internally used collector (filed bug 288242 to track this). You can workaround this for now by computing the core context for your processor(s) yourself: CompletionProposalCollector collector= new CompletionProposalCollector(cu, true); collector.setRequireExtendedContext(true); // set additional options cu.codeComplete(getInvocationOffset(), collector); collector.getContext();
Thanks! I'll try that.
Created attachment 146328 [details] fix The patch is a bit hacky but I couldn't find any good way to make this work other than by resetting the core context to null to force recomputation. Shawn, can you sanity check this patch?
Created attachment 146332 [details] fix that compiles on 3.3
Committed to head and 3.2.x maintenance branch.
Created attachment 146334 [details] mylyn/context/zip
Steffen, just a quick question: do you use your own completion proposal collector? If so, I guess it already set to use an extended context, right?
(In reply to comment #15) > Steffen, just a quick question: do you use your own completion proposal > collector? If so, I guess it already set to use an extended context, right? Yes. Mylyn's computer extends JavaCompletionProposalComputer which sets up the collector and sets the extended flag but by the time it is invoked the cached copy in the invocation context has already been created by TemplateCompletionProposalComputer I think.
>but by the time it is invoked the cached >copy in the invocation context has already been created by >TemplateCompletionProposalComputer I think. OK, that helps. This also means you use your own collector instance. We mainly need the cache in 'JavaContentAssistInvocationContext' for two reasons: - give context to those that actually don't do a Java code assist (e.g. keyword or spelling proposals) - compute keywords only once Now, if a computer already has its own collector then we should always use that one instead of the cached one. This makes fixing bug 288242 easy.
Great. The work-around in Mylyn will be available in 3.2.2 and later versions. We'll remove it once support for Eclipse 3.4 and 3.5 has ended.
*** Bug 294233 has been marked as a duplicate of this bug. ***
