[PATCH] Implement DR61: Address of ambiguous bound methods should be disallowed

[Richard Smith]

On Mon, Jun 10, 2013 at 3:58 PM, David Majnemer
<david.majnemer at gmail.com> wrote:
> On Mon, Jun 10, 2013 at 3:51 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
>>
>> On Mon, Jun 10, 2013 at 3:25 PM, David Majnemer
>> <david.majnemer at gmail.com> wrote:
>> > On Mon, Jun 10, 2013 at 12:00 PM, Richard Smith <richard at metafoo.co.uk>
>> > wrote:
>> >>
>> >> On Sat, Jun 8, 2013 at 1:14 AM, David Majnemer
>> >> <david.majnemer at gmail.com>
>> >> wrote:
>> >> > On Fri, Jun 7, 2013 at 10:12 PM, Richard Smith
>> >> > <richard at metafoo.co.uk>
>> >> > wrote:
>> >> >>
>> >> >> Please remove the FIXME from dr0xx.cpp.
>> >> >
>> >> >
>> >> > Done.
>> >> >
>> >> >>
>> >> >>
>> >> >> I'm not sure the changes to p2-resolve-single-template-id.cpp are
>> >> >> right -- we should have resolved the name to a single static member
>> >> >> function in those cases. EDG thinks those cases are valid.
>> >> >
>> >> >
>> >> > You are totally correct. I *wrongly* tried to rationalize GCC's
>> >> > behavior
>> >> > as
>> >> > it seemed believable. That's the last time I do that...
>> >> >
>> >> > I've attached a patch that corrects for this.
>> >>
>> >> Thanks!
>> >>
>> >> I think we should actually be fixing up the & operand to point to the
>> >> resolved function in CheckAddressOfOperand, rather than just checking
>> >> it. Does (for instance) decltype(&a.static_fn) work with the current
>> >> approach?
>> >
>> >
>> > Neither my patch nor EDG allows decltype(&a.static_fn).
>>
>> Sorry, the case I meant was this one:
>>
>> struct A { template<typename T> static void f(); } a;
>> decltype(&a.f<int>) p;
>
>
> Both my patch and EDG allow this.

Seems a bit wasteful to resolve the function twice, but OK.

The diagnostic in expr.unary.op/p4.cpp isn't very good, please add a
FIXME for that before you commit.