On Mon, Jun 10, 2013 at 3:58 PM, David Majnemer <[email protected]> wrote: > On Mon, Jun 10, 2013 at 3:51 PM, Richard Smith <[email protected]> > wrote: >> >> On Mon, Jun 10, 2013 at 3:25 PM, David Majnemer >> <[email protected]> wrote: >> > On Mon, Jun 10, 2013 at 12:00 PM, Richard Smith <[email protected]> >> > wrote: >> >> >> >> On Sat, Jun 8, 2013 at 1:14 AM, David Majnemer >> >> <[email protected]> >> >> wrote: >> >> > On Fri, Jun 7, 2013 at 10:12 PM, Richard Smith >> >> > <[email protected]> >> >> > 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. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
