[clangd-dev] Prototyping a "type hierarchy" request

Sam McCall via clangd-dev clangd-dev at lists.llvm.org
Tue Aug 28 09:28:14 PDT 2018

On Tue, Aug 28, 2018 at 4:53 PM Simon Marchi <simon.marchi at polymtl.ca>

> On 2018-08-28 02:21, Sam McCall wrote:
> > On Mon, Aug 27, 2018, 22:22 Simon Marchi via clangd-dev <
> > clangd-dev at lists.llvm.org> wrote:
> >> whereas for type hierarchy we would also want non-virtual overrides.
> >>
> > Dumb question, what are non-virtual overrides? I'm thinking CRTP, but
> > I'm
> > probably overthinking this :-)
> Not sure I understand you question.  But simply, if you have this:
> struct A
> {
>    void method ();
> };
> struct B : A
> {};
> struct C : B
> {
>    void me^thod ();
> };
> I think that doing a type hierarchy request at the caret should still
> tell you that a definition of the method you are targeting is present in
> A and not in B, even if they are not marked virtual.
Ah, right. I don't think this is usually considered overriding.
I'd be surprised to see this in a type hierarchy, as I'd usually consider
them unrelated functions.
(And the compiler mostly does too, so you'll probably have to iterate over
all the base's members).

There are cases where this hiding is used for overriding-like effect with
compile-time polymorphism, like when a CRTP base class B<Derived> provides
a default implementation of foo(), and invokes it as Derived::foo(). But
this is probably the exception rather than the rule, it seems OK to leave
it out in the first cut at least.

> One approach would be to use the XRefs APIs that are landing, make
> > "overrides" a role, and allow the payload to be a symbol ID rather than
> > a
> > location.
> I'll take a look, but I am not sure how this solves the problem of
> extracting the required information from the AST.

Sorry, it doesn't - I was speculating about how to (later) tie this to the
index to get the derived types.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/clangd-dev/attachments/20180828/9f6eeeb7/attachment-0001.html>

More information about the clangd-dev mailing list