[cfe-commits] r82293 - in /cfe/trunk: include/clang/Sema/CodeCompleteConsumer.h lib/Sema/CodeCompleteConsumer.cpp test/CodeCompletion/functions.cpp

[Douglas Gregor]

On Sep 21, 2009, at 3:44 PM, Chris Lattner wrote:

>
> On Sep 21, 2009, at 2:33 PM, Douglas Gregor wrote:
>
>>
>> On Sep 21, 2009, at 2:12 PM, Chris Lattner wrote:
>>
>>>
>>> On Sep 18, 2009, at 3:15 PM, Douglas Gregor wrote:
>>>
>>>> Author: dgregor
>>>> Date: Fri Sep 18 17:15:54 2009
>>>> New Revision: 82293
>>>>
>>>> URL: http://llvm.org/viewvc/llvm-project?rev=82293&view=rev
>>>> Log:
>>>> Introduce code completion strings, which describe how to *use* the
>>>> results of code completion, e.g., by providing function call syntax
>>>> with placeholders for each of the parameters.
>>>
>>> Very nice Doug,
>>>
>>> Would it make sense to support "informational" Chunks which would  
>>> be shown in the list of possibilities the user would select from,  
>>> but would not be inserted?  This would allow you to say that  
>>> "Base::N" is hidden in a base class, but "N" is in "class foo".
>>>
>>> In fact, when completing P->  for members that are not in P's  
>>> direct class (but are in base classes) it would be nifty to show  
>>> which base class they come from in the popup.  What do you think?
>>
>>
>> I like it. We currently provide qualification when the name in the  
>> base class (or an outer context) is *hidden*, because in that case  
>> we show the qualification is needed for us to have any chance of  
>> doing the right thing.
>
> Right, I'd expect to see something like this in the 'popup' for P->
>
> field1
> field2         - Base class 'foo'
> Base::field2   - Base class 'Base', hidden by 'foo::field2'
> field3
>
> etc, where field1/field3 are direct fields in *p.  This way you  
> don't get noise when dealing with simple structs with no base  
> classes, etc.

I don't particularly like the idea of putting these longish text  
strings into the output, and would prefer something shorter and more  
subtle:

field1
<i>foo::</i>field2
field3
Base::field2

Two important differences:
   - the "foo::" for the first field2 is meant to be informative, to  
show that we're coming from a base class but without inserting any text.
   - hidden decls should be ranked worse than non-hidden decls.

Right now, fields found in base classes are ranked worse than fields  
in the most-derived class, so we actually get something lke

	field1
	field3
	field2
	Base::field2

which probably isn't what we want.

	- Doug