PATCH: don't mark pure derived method odr because of a qualified call to base method

[Richard Smith]

On Wed, Feb 13, 2013 at 4:16 PM, John McCall <rjmccall at apple.com> wrote:

> On Feb 13, 2013, at 3:40 PM, Nick Lewycky <nlewycky at google.com> wrote:
>
> On 13 February 2013 10:53, John McCall <rjmccall at apple.com> wrote:
>
>> On Feb 13, 2013, at 12:53 AM, Nick Lewycky <nlewycky at google.com> wrote:
>> > 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.
>> >
>> > 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.
>>
>> Ugh.  I am not thrilled by the idea of emitting massive amounts of code
>> because something *might* devirtualize to it.
>>
>> Also, this potentially requires template instantiation.
>>
>
> Me neither. However, Sema and CodeGen are already colluding to do this.
> See SemaExpr.cpp:11168 (MarkExprReferenced), which may trigger
> instantiation, and CGExprCXX.cpp:200 (EmitCXXMemberCallExpr) which assumes
> the potential callee was already instantiated.
>
>
> If we're willing to break some of the majestic beauty of the
> frontend-isolated optimizer, we could queue up a late module pass which
> 1) recognizes that we've emitted a reference to something that we're
> required to define in every translation unit that references it (easy to do
> with metadata),
> 2) goes back to Sema and IR-gen to produce that code, and
> 3) restarts the optimizer on the new functions.
> Repeat until hopefully-rapid convergence.
>

That sounds like a path to optimization-dependent diagnostics, which we
have previously gone to lengths to avoid. This case seems less severe,
since it is likely that the diagnostics will be produced in *some*
translation unit, but I still find it concerning.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130213/76a22463/attachment.html>