[cfe-commits] r82293 - in /cfe/trunk: include/clang/Sema/CodeCompleteConsumer.h lib/Sema/CodeCompleteConsumer.cpp test/CodeCompletion/functions.cpp
Douglas Gregor
dgregor at apple.com
Tue Sep 22 15:23:01 PDT 2009
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
More information about the cfe-commits
mailing list