[clangd-dev] Landing support for LSP protocol extensions?

[Sam McCall via clangd-dev]

Hi Nathan,

I don't think we have a clear idea/policy for extensions, but we should.
I think the most important factors (for all features, standard or not):
 - editor support: how many users will the feature be available to?
 - standardization: is this feature fairly stable, and likely to be adopted
by more editors over time?
 - utility: does the feature add a lot of value for users?
 - complexity: is this feature hard to implement in clangd, or constrain
future work? does it complicate the protocol a lot?

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

Subtypes on the other hand are complex to implement and have costs
(increased index size).

Regarding hiding extensions:
 - 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.
 - 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.

[1] Assuming an AST-only implementation that will fail to find supertypes
when the current file sees only a class's forward declaration.

On Fri, Jan 11, 2019 at 1:48 AM Nathan Ridge via clangd-dev <
clangd-dev at lists.llvm.org> wrote:

> Hi there!
>
> 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.
>
> 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).
>
> (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.)
>
> Is clangd interested in support for protocol extensions like this landing,
> in any form, prior to their standardization in LSP?
>
> If so, are there any measures that should be taken to reflect that the
> protocol is not yet standard? For example:
>
> * 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.
>
> * The protocol could be available under the standard name, but behind a
> command-line flag and not enabled by default.
>
> Any thoughts on this subject are appreciated!
>
> Thanks,
> Nate
>
> [1] https://reviews.llvm.org/D56370
> [2] https://github.com/Microsoft/vscode-languageserver-node/pull/426
> [3] https://github.com/theia-ide/theia/pull/3802
> [4] https://github.com/cquery-project/cquery
> _______________________________________________
> clangd-dev mailing list
> clangd-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/clangd-dev/attachments/20190111/37517039/attachment-0001.html>