[clangd-dev] Querying the index for derived classes

[Ilya Biryukov via clangd-dev]

On Sun, Jan 13, 2019 at 7:25 PM Nathan Ridge <zeratul976 at hotmail.com> wrote:

> > 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
ranking.
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).

> 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.


> > 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?
>
> Thanks,
> Nate



-- 
Regards,
Ilya Biryukov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/clangd-dev/attachments/20190114/b8914156/attachment.html>