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

[Sam McCall via clangd-dev]

On Sun, Jan 13, 2019 at 5:49 AM Nathan Ridge <zeratul976 at hotmail.com> wrote:

> 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.
>
Good point - the references wouldn't mention the original class name, which
is confusing.
Thinking about the physical layout of source code, to find (direct) bases
today one can just go-to-def and then see the list.
So a reference-style list of bases doesn't add much value (though a
hierarchical one still might).

And thinking more about the interaction - it seems that a type hierarchy
that shows both base and derived classes might be most useful. Do you know
why the super/sub types are proposed as separate methods?

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.
>
Sorry, I did mean here exposing (an extension of) the reference API, rather
than the suggested supertypes API. Not sure it's a good idea, but it'd be a
different model.

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.)
>
VSCode in particular seems to get all its structure-awareness from language
servers. Do you know where it gets data for type hierarchy? Practically
speaking, what VSCode wants seems to drive about 80% of what gets
standardized.

> 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.
>
Sounds good, thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/clangd-dev/attachments/20190114/9ac1e39c/attachment.html>