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

<div class="HOEnZb"><div class="h5"><br>
>> >> On Fri, Jun 7, 2013 at 9:20 PM, David Majnemer<br>
>> >> <<a href="mailto:david.majnemer@gmail.com">david.majnemer@gmail.com</a>><br>
>> >> wrote:<br>
>> >> > Sorry, I accidentally forgot to mark the test as passing in<br>
>> >> > dr0xx.cpp.<br>
>> >> ><br>
>> >> > An updated patch is attached.<br>
>> >> ><br>
>> >> > --<br>
>> >> > David Majnemer<br>
>> >> ><br>
>> >> ><br>
>> >> > On Fri, Jun 7, 2013 at 9:15 PM, David Majnemer<br>
>> >> > <<a href="mailto:david.majnemer@gmail.com">david.majnemer@gmail.com</a>><br>
>> >> > wrote:<br>
>> >> >><br>
>> >> >> clang currently disallows bound methods from having their address<br>
>> >> >> taken<br>
>> >> >> but sometimes allows them if the method is overloaded in some way.<br>
>> >> >><br>
>> >> >> The attached patch implements DR61 [*] which affirms that<br>
>> >> >> expressions<br>
>> >> >> containing unresolved member access should be disallowed when<br>
>> >> >> performing<br>
>> >> >> "address of" operations.<br>
>> >> >><br>
>> >> >><br>
>> >> >> [*] <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#61" target="_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#61</a><br>
>> >> >><br>
>> >> >> Thanks<br>
>> >> >> --<br>
>> >> >> David Majnemer<br>
>> >> ><br>
>> >> ><br>
>> ><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div></div>