Bug 162968 - Content Assist for undeclared local variable should prioritize unbound names
Summary: Content Assist for undeclared local variable should prioritize unbound names
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.3 M4   Edit
Assignee: David Audel CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-31 13:34 EST by Markus Keller CLA
Modified: 2006-12-11 14:21 EST (History)
1 user (show)

See Also:


Attachments
Proposed fix (9.84 KB, patch)
2006-11-06 11:41 EST, David Audel CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Keller CLA 2006-10-31 13:34:54 EST
I20061031-0656

Content Assist for undeclared local variable should prioritize unbound names. In this example, there's a resolved binding for vDefined, but none for vUnknown. Therefore, vUnknown should have higher priority than the other.

public class Tst {
	int vDefined;

	void m(final int arg) {
		int v // content assist proposes vDefined first
		
		System.out.println(vUnknown);
		System.out.println(vDefined);
	}
}
Comment 1 Dani Megert CLA 2006-11-01 03:19:26 EST
+1
Comment 2 David Audel CLA 2006-11-02 07:26:57 EST
I think that vUnknown should not have higher relevance but that vDefined should not be proposed because it's an existing field.
Comment 3 Markus Keller CLA 2006-11-02 09:49:25 EST
Yes, not proposing names with an unquestionable binding would also be fine with me.
Comment 4 Dani Megert CLA 2006-11-02 10:02:04 EST
Mmh, this would destroy the following scenario/usage
  int foo= 3;
and would like to use code assist to add foo2? Currently I can do
  int f<code assist> ==> int foo<type '2'>
Comment 5 David Audel CLA 2006-11-02 10:33:04 EST
Answer to comment 4:

If i correctly understand, you want to propose 'foo' in a scenario like

{
  int foo = 3;
  int fo| // do ctrl + space at |
  foo = 25;
}

and then type '2' to have

{
  int foo = 3;
  int foo2
  foo = 25;
}

For me this doesn't look like an undeclared name proposal.
It look like a proposal of an already defined named and would be another feature. This new features could be useful for users and should work even of there is no undeclared name.
e.g.
{
  int foo = 3;
  int fo| // do ctrl + space at |
}

Therefore if you are agree with me, we should file a features request in JDT/Core.
Comment 6 Dani Megert CLA 2006-11-02 11:07:20 EST
I thought this would be a regression to 3.2 but since it wasn't possible there I suggest to simply go along comment 2.
Comment 7 David Audel CLA 2006-11-02 11:15:06 EST
I think that you mistake for this scenario

class Foo {
  {
    Foo foo = null;
    Foo fo| // do ctrl + space at |
  }
}

In this case 'foo2' is still proposed.
Comment 8 David Audel CLA 2006-11-06 11:41:08 EST
Created attachment 53306 [details]
Proposed fix

Already defined variables won't be proposed.
Comment 9 David Audel CLA 2006-11-06 11:44:07 EST
Released for 3.3 M4.

Test added
  CompletionTests#testCompletionVariableName34()
Comment 10 Olivier Thomann CLA 2006-12-11 14:21:41 EST
Verified for 3.3M4 with I20061211-1119