<div dir="ltr">Thinking about this issue more, I'd like to retract this patch. Consider the case where we're implementing the rule that all ODR-used inline functions must have a definition. If Derived::fn is marked inline, we'll see a fictitious use of it and reject a valid translation unit.<div>

<br></div><div style>My next plan is to remove this code from Sema entirely and do the equivalent work inside codegen proper. No reason it can't keep track of probable virtual function targets when writing out a virtual dispatch.</div>

<div style><br></div><div style>Nick</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 12 February 2013 19:30, Nick Lewycky <span dir="ltr"><<a href="mailto:nlewycky@google.com" target="_blank">nlewycky@google.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I failed to produce a concise explanation of the patch, so I'll lead off with the testcase:</div>

<div><br></div><div>  struct Base { virtual void fn() { } };</div><div>  struct Derived : public Base { virtual void fn() = 0;</div>
<div>    void test() { Base::fn(); /* triggers an ODR-use of Derived::fn() */ }</div><div>  };</div><div><br></div><div>This is because we repurpose the odr bit on virtual functions to mean "it would be convenient for codegen to emit this", to help devirtualization for instance. This is implemented in Sema with a scan through all known derived classes when building a member expression, in this case "this->Base::fn". This patch makes that scan skip pure methods.</div>


<div><br></div><div>Patch attached, please review.<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Nick</div><div><br></div></font></span></div>


</blockquote></div><br></div>