<div dir="ltr">Hi Nathan,<div><br></div><div>I don't think we have a clear idea/policy for extensions, but we should.</div><div>I think the most important factors (for all features, standard or not):</div><div> - editor support: how many users will the feature be available to?</div><div> - standardization: is this feature fairly stable, and likely to be adopted by more editors over time?</div><div> - utility: does the feature add a lot of value for users?</div><div> - complexity: is this feature hard to implement in clangd, or constrain future work? does it complicate the protocol a lot?</div><div><br></div><div>Regarding supertypes: editor support and standardization are both at a very early stage. On the other hand, it's a useful feature that's easy to implement[1]. I wouldn't be opposed as-is.</div><div>One alternative to consider is implementing it as an extension to FindReferences (the supertype -> subtype relationship is a type of reference.) This might be easier to standardize, as it seems giving a ref-type mask to FindReferences would enable a bunch of these types of features (and editors could reuse UI with little effort). It's unclear to me how important showing the whole hierachy is.<br></div><div><br></div><div>Subtypes on the other hand are complex to implement and have costs (increased index size).</div><div><br></div><div>Regarding hiding extensions:</div><div> - one concern is stability: we may want to expose features while reserving the right to remove or totally change them later. This isn't intrinsically tied to standardization - we can commit to supporting extensions. Flags/capabilities etc might make sense here.</div><div> - another is namespace conflicts between our extension and future standard/other extensions. The problem with a clangd namespace is then editors need to know about clangd, not just the extension in general. I'd suggest trying to adopt/encourage shared names for extensions among the LSP community rather than namespacing, myself.</div><div><br></div><div>[1] Assuming an AST-only implementation that will fail to find supertypes when the current file sees only a class's forward declaration.</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jan 11, 2019 at 1:48 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 there!<br>
<br>
I've written a patch [1] to add support to clangd for the "textDocument/superTypes" request, which, given the location of a symbol naming a class type, returns information about its base classes.<br>
<br>
This is not part of the LSP specification yet, though it has been proposed for addition [2], and has been implemented in at least one client (Theia [3], not merged yet).<br>
<br>
(There is also a "textDocument/subTypes" request in the proposal, which returns information about derived classes. That's more challenging to implement; stay tuned for a separate post about that.)<br>
<br>
Is clangd interested in support for protocol extensions like this landing, in any form, prior to their standardization in LSP?<br>
<br>
If so, are there any measures that should be taken to reflect that the protocol is not yet standard? For example:<br>
<br>
* cquery (another C++ language server [4]) puts non-standard protocols into a "$cquery" namespace, e.g. "$cquery/typeHierarchy" rather than "textDocument/typeHierarchy". clangd could potentially do the same.<br>
<br>
* The protocol could be available under the standard name, but behind a command-line flag and not enabled by default.<br>
<br>
Any thoughts on this subject are appreciated!<br>
<br>
Thanks,<br>
Nate<br>
<br>
[1] <a href="https://reviews.llvm.org/D56370" rel="noreferrer" target="_blank">https://reviews.llvm.org/D56370</a><br>
[2] <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>
[3] <a href="https://github.com/theia-ide/theia/pull/3802" rel="noreferrer" target="_blank">https://github.com/theia-ide/theia/pull/3802</a><br>
[4] <a href="https://github.com/cquery-project/cquery" rel="noreferrer" target="_blank">https://github.com/cquery-project/cquery</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>