<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 28, 2018 at 4:53 PM Simon Marchi <<a href="mailto:simon.marchi@polymtl.ca">simon.marchi@polymtl.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2018-08-28 02:21, Sam McCall wrote:<br>
> On Mon, Aug 27, 2018, 22:22 Simon Marchi via clangd-dev <<br>
> <a href="mailto:clangd-dev@lists.llvm.org" target="_blank">clangd-dev@lists.llvm.org</a>> wrote:<br>
>> whereas for type hierarchy we would also want non-virtual overrides.<br>
>> <br>
> Dumb question, what are non-virtual overrides? I'm thinking CRTP, but <br>
> I'm<br>
> probably overthinking this :-)<br>
<br>
Not sure I understand you question.  But simply, if you have this:<br>
<br>
struct A<br>
{<br>
   void method ();<br>
};<br>
<br>
struct B : A<br>
{};<br>
<br>
struct C : B<br>
{<br>
   void me^thod ();<br>
};<br>
<br>
<br>
I think that doing a type hierarchy request at the caret should still <br>
tell you that a definition of the method you are targeting is present in <br>
A and not in B, even if they are not marked virtual.<br></blockquote><div>Ah, right. I don't think this is usually considered overriding.</div><div>I'd be surprised to see this in a type hierarchy, as I'd usually consider them unrelated functions.</div><div>(And the compiler mostly does too, so you'll probably have to iterate over all the base's members).</div><div><br></div><div>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.</div><div> </div><div><br></div><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">> One approach would be to use the XRefs APIs that are landing, make<br>> "overrides" a role, and allow the payload to be a symbol ID rather than <br>> a<br>> location.<br>I'll take a look, but I am not sure how this solves the problem of <br>extracting the required information from the AST.</blockquote><div>Sorry, it doesn't - I was speculating about how to (later) tie this to the index to get the derived types.</div></div></div></div>