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

[David Majnemer]

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).


>
> >> On Fri, Jun 7, 2013 at 9:20 PM, David Majnemer <
> david.majnemer at gmail.com>
> >> wrote:
> >> > Sorry, I accidentally forgot to mark the test as passing in dr0xx.cpp.
> >> >
> >> > An updated patch is attached.
> >> >
> >> > --
> >> > David Majnemer
> >> >
> >> >
> >> > On Fri, Jun 7, 2013 at 9:15 PM, David Majnemer
> >> > <david.majnemer at gmail.com>
> >> > wrote:
> >> >>
> >> >> clang currently disallows bound methods from having their address
> taken
> >> >> but sometimes allows them if the method is overloaded in some way.
> >> >>
> >> >> The attached patch implements DR61 [*] which affirms that expressions
> >> >> containing unresolved member access should be disallowed when
> >> >> performing
> >> >> "address of" operations.
> >> >>
> >> >>
> >> >> [*] http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#61
> >> >>
> >> >> Thanks
> >> >> --
> >> >> David Majnemer
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130610/d35943ae/attachment.html>