Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 419619

Summary:	[content assist] Perfect matches should be sorted higher
Product:	[Eclipse Project] JDT	Reporter:	Robin Stocker <robin>
Component:	Core	Assignee:	JDT-Core-Inbox <jdt-core-inbox>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	normal
Priority:	P3	CC:	daniel_megert, eostroukhov, Lars.Vogel, marcel.bruch, nikolaymetchev
Version:	4.4	Keywords:	helpwanted
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:
Bug Depends on:
Bug Blocks:	417961

Description Robin Stocker

2013-10-16 13:57:16 EDT

Originally reported as separate bug, see bug 417961 comment 6:

- Quick Fix does not rate perfect matches higher
and there is a third case which is interesting: content assist - it has the same sorting issue as the Quick Fix. If we improve/fix content assist in JDT Core to set better relevances, it will also fix the Quick Fix, because those proposals are also computed via content assist.

Comment 1 Dani Megert

2013-10-17 03:53:43 EDT

(In reply to Marcel Bruch from bug 417961 comment 8)
> It looks like there is no code yet that provides access to RHS of the
> assignment in CompletionEngine. The referenceContext does not provide that
> information (only field declarations but not it's initializations). Any idea
> how this should be solved?
> 
> Should the type resolution consider the import statements (which are
> available) and do a "is-proposed-type-a-super-type-of-any-imported-type"
> thingy?

If the proposal should really be smarter then it needs the imports and also the hierarchy, which, as we know, might be expensive. That's why we currently don't do this. Instead we remember the already used types in the UI layer and then use them to suggest smarter proposals (ContentAssistHistory.RHSHistory).

Comment 2 Marcel Bruch

2013-10-17 04:16:31 EDT

(In reply to Dani Megert from comment #1)
> If the proposal should really be smarter then it needs the imports and also
> the hierarchy, which, as we know, might be expensive. 

Just to be clear (and make sure I did not oversee anything): I have no information of the actual RHS when CompletionEngine is triggered. So, I'd only guess that any supertype of any imported type would be a better fit than others - which is still a heuristic which will fail in many cases.

It's not exactly what is requested.

> That's why we
> currently don't do this. Instead we remember the already used types in the
> UI layer and then use them to suggest smarter proposals
> (ContentAssistHistory.RHSHistory).

Understood. Is this a +1 to build the supertype hierarchy for each imported type and rank proposals higher that are in this set? At least as an experiment? I'd like to know beforehand if this is the considered best solution.

Comment 3 Dani Megert

2013-11-07 06:26:06 EST

(In reply to Marcel Bruch from comment #2)

Sorry for the delay. This somehow got lost in my inbox.


> (In reply to Dani Megert from comment #1)
> > If the proposal should really be smarter then it needs the imports and also
> > the hierarchy, which, as we know, might be expensive. 
> 
> Just to be clear (and make sure I did not oversee anything): I have no
> information of the actual RHS when CompletionEngine is triggered. 

Correct.


> Is this a +1 to build the supertype hierarchy for each imported
> type and rank proposals higher that are in this set? At least as an
> experiment? I'd like to know beforehand if this is the considered best
> solution.

Yes, we should try this to see how it feels, but abort when the given progress monitor is cancelled (after a timeout). See CompletionProposal.CONSTRUCTOR_INVOCATION for more details.

Comment 4 Dani Megert

2017-11-20 10:46:20 EST


*** This bug has been marked as a duplicate of bug 175326 ***