<div dir="ltr">Hi Nathan,<div><br></div><div>This sounds like a nice feature, though there's some complexity.</div><div><br></div><div>One problem is that as you say we'll need to add index data for this, but the feature is neither standardized nor widely adopted. So it's a tough tradeoff. (I'm not sure how much the increase to disk and serving structures is likely to be).</div><div><br></div><div>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).</div><div>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.</div><div>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.</div><div><br></div><div>Otherwise an alternative is storing related symbols as you say (either bases in the Symbol object like you say, or separately like Refs).</div><div>One limitation here is that subtypes are not strictly a symbol->symbol relationship when templates are considered. e.g. you can imagine class String : vector<char>. Using type tokens (like the expected-types work does) will give the right answer here. Technically you can also have a template specialization inheriting from a base class, but that seems likely to be rarer.</div><div><br></div><div>Regarding Apple's index-while-build: we're mostly not using that in clangd's own indexing for several reasons:</div><div> - the big advantage of reusing the actual build work and UI relies on users building with a new clang, which we can't assume</div><div> - much of it hasn't been (still isn't?) available in upstream LLVM</div><div> - it doesn't provide data structures suitable for *serving*, it's just data extraction. We do use a bit of the infrastructure to walk ASTs.</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jan 11, 2019 at 2:14 AM Nathan Ridge via clangd-dev <<a href="mailto:clangd-dev@lists.llvm.org">clangd-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi!<br>
<br>
I'm looking at implementing support for a proposed LSP protocol extension "textDocument/subTypes", which, given the location of a symbol naming a class type, returns information about its derived classes.<br>
<br>
(For context, this is part of the same Type Hierarchy proposal [1] which also includes "textDocument/superTypes", which I've already implemented and posted about separately [2].)<br>
<br>
Unlike "superTypes", for which all the necessary information is in the AST, "subTypes" requires an index query to locate derived types.<br>
<br>
Based on my current understanding of clangd's index, the information currently stored in the index is not sufficient to implement such a query efficiently. It seems to me that the index would need a mechanism to record relationships between symbols; for example, for each symbol, to store a list of pointers to other symbols which are the derived classes.<br>
<br>
Is there interest in extending the type of information stored in clangd's index along these lines?<br>
<br>
I also recall a presentation by Apple [3] about storing relationships like this in the index. Does anyone know what the current status of that effort is?<br>
<br>
Thanks,<br>
Nate<br>
<br>
[1] <a href="https://github.com/Microsoft/vscode-languageserver-node/pull/426" rel="noreferrer" target="_blank">https://github.com/Microsoft/vscode-languageserver-node/pull/426</a><br>
[2] <a href="http://lists.llvm.org/pipermail/clangd-dev/2019-January/000238.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/clangd-dev/2019-January/000238.html</a><br>
[3] <a href="https://www.youtube.com/watch?v=jGJhnIT-D2M" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=jGJhnIT-D2M</a><br>
_______________________________________________<br>
clangd-dev mailing list<br>
<a href="mailto:clangd-dev@lists.llvm.org" target="_blank">clangd-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev</a><br>
</blockquote></div>