[clangd-dev] Querying the index for derived classes
Sam McCall via clangd-dev
clangd-dev at lists.llvm.org
Mon Jan 14 02:20:18 PST 2019
On Mon, Jan 14, 2019 at 10:46 AM Ilya Biryukov <ibiryukov at google.com> wrote:
> On Sun, Jan 13, 2019 at 7:25 PM Nathan Ridge <zeratul976 at hotmail.com>
>> > We do have plans to add some type information to the index for the
>> > purposes of code completion ranking (boost results that have the
>> > right type).
>> > This will need to include the base types (e.g. so that when a Shape& is
>> > expected, a Circle& will match it). So maybe we can use the same data
>> > and query for (kind=type && type=SomeBase) to find derived types.
>> > Ilya is working on this, this might be a nice solution without
>> > expanding the index, if expected-types ranking and subtypes don't
>> > turn out to be too divergent.
>> Thanks, this is an interesting direction to explore.
>> I looked briefly at the expected-types patches that have landed so far.
>> Do I understand correctly that there are plans to expand the field
>> Symbol::Type to also encode the types of the base classes?
> We plan to do this for expected types at some point, however my natural
> instinct would be to avoid using this for anything other than completion
> Not saying this wouldn't work, but my assumption is that storing
> hierarchies separately will be cheap both in storage and performance, make
> the intention of the code querying them clearer and would allow to
> generalize easier for the template hierarchy (for go to template
> specializations/explicit instantiations).
Fair enough, we should measure. I'm slightly nervous about thousands of
tiny posting lists in dex, but maybe my intuition is failing me.
At least we should reuse (some of) the code that encodes types opaquely for
the index, though.
> One limitation here is that subtypes are not strictly a
>> > symbol->symbol relationship when templates are considered.
>> Good point. Indeed, in the other C++ indexer that I'm familiar with
>> (Eclipse CDT's), types have their own representation in the index (which
>> includes a way to represent e.g. template specializations), and bases use
>> that representation.
> So we have a (trivial for now) encoding that allows types to be
attributes, query for them etc:
But we don't have them as first-class entities in the index like Symbols
and References are. My gut feeling is we might be able to get away without
this, by attaching them to symbols in the right way.
>> > Regarding Apple's index-while-build:
>> > [...]
>> > We do use a bit of the infrastructure to walk ASTs.
>> Would that be the facilities in the "clang/Index/*" headers that e.g.
>> SymbolCollector uses?
> Yes, that's right.
> Ilya Biryukov
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the clangd-dev