[cdt-dev] Using ICHelpInvocationContext in ICHelpProvider.getMatchingFun

["Ploett, Norbert" <norbert.ploett@xxxxxxxxxxx>]

Hello folks,

here is another help provider issue (my favorite :-)). OK, consider the
following mini-example:

Sorter.h
==========snip========== 
class Sorter {
public:
	void sort(double* array);
protected:
	void internalSort();
}
==========snap========== 

Sorter.cpp
==========snip========== 
void Sorter::sort(double* array)  {
	internal // <-- User presses ctrl-blank for content assist here
}
==========snap========== 

When the user requests content assist after typing "internal" in the
implementation of sort() every contributed ICHelpProvider gets a call to
it's getMatchingFunctions() and has to figure out, based on the context,
which completions can be offered. In the example eligible candidates
are:

- Globally (C-style) functions starting with "internal"
- Public and protected methods from Sorter or it's base classes starting
with "internal"
- Private methods from Sorter starting with internal.

The point I want to make is that the context information that is
currently supplied to the getMatchingFunctions() method is not
sufficient to determine which candidates are eligible. Currently the
context contains a reference to the project (IProject) and the
translation unit (ITranslationUnit). 

The reference to the translation unit is quite valuable and will be
required to resolve the issue but additional information is needed,
namely the exact place in the source code (i.e. the offset) where the
content assist request was triggered. When the offset is given then the
ITranslationUnit can find the surrounding element (getElementAtOffset())
and from here visibility rules can be evaluated.

So my plea is to include a reference to the position in the source (such
as the offset) in ICHelpInvocationContext which will allow the help
provider to make better guesses about which candidates to propose.

Any opinions on this?


Tnx


Norbert Ploett