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

[Nathan Ridge via clangd-dev]

Hi Sam,

Thanks for your feedback!

> 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]
> 
> [1] Assuming an AST-only implementation that will fail to find 
> supertypes when the current file sees only a class's forward declaration.

Indeed, that is how my current implementation works.

>From a user point of view, it would be nice if it worked on types that are only forward-declared; once we figure out subtypes, we can probably extend supertypes to apply the same approach.

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

I can see modelling subtypes as a type of reference. It's less clear for supertypes: if I have a class with five bases, I want to report five results in my query, but my class's name is only mentioned once.

Even for subtypes, this implementation approach does not seem sufficient for the current proposed API. Annotating references as bases gives me the locations of base-clauses, but the API wants the name of the derived type. I don't think we can reliably get from one to the other without building an AST for the file in question.

As far as the API itself is concerned, there is some logic in formulating the API in terms of references. I believe cquery supports extensions that return subsets of references which are calls, bases, etc. However, it does this in addition to supporting a type hierarchy query, and a type hierarchy view does seem to be popular in editors. (Just among the editors I know, Eclipse, VSCode, and IntelliJ all have one, with Theia soon to follow.)

> Regarding hiding extensions:
> [...]
>  I'd suggest trying to adopt/encourage shared names for extensions 
> among the LSP community rather than namespacing, myself.

That sounds reasonable.

It sounds like, for the time being, I should go ahead and submit my current AST-only superTypes implementation for review, using the proposed standard name, and see what happens. I'll clean up the patch and do so.

Thanks,
Nate