[PATCH?] 'this' in typedefs, possibly overly complicated code in other 'this' checks?

[Richard Smith]

How does this deal with the case where 'this' appears in a declarator for
an out-of-line definition of a static member function? In that case, we
don't know we're parsing a static member function declaration until *after*
we've already parsed the 'this' expression. I believe the existing
complexity was aimed at correctly handling that case; it seems surprising
that we don't have any tests for it.

On Wed Jan 15 2014 at 3:33:07 PM, Harald van Dijk <harald at gigawatt.nl>
wrote:

> Hi all,
>
> This came up on StackOverflow recently:
>
> 'this' is rejected by clang in static member functions:
>
> error: 'this' cannot be used in a static member function declaration
>   static auto f() -> decltype(this);
>                               ^
>
> However, what the standard actually says is that 'this' is not allowed
> except in non-static member functions (and some more bits not relevant
> here). Declarations that look like member functions but aren't, not even
> static ones, shouldn't allow 'this' either.
>
>   typedef auto f() -> decltype(this);
>
> Looking to see what clang implements, I was very surprised. There is
> already perfectly functional code that rejects 'this' in 'friend'
> functions, and that code is not reused for 'static' functions (and
> 'typedef's): instead, the checks have effectively been rewritten for
> 'static'.
>
> I'm wondering, why is that? If I do attempt to re-use the existing code,
> as in the attached patch, then the only changes in the test results are
> actually correct, as references to non-static data members are permitted
> even in 'static' functions, so long as they appear in unevaluated
> expressions. There is even a FIXME comment about this in the test. But
> I'm sure the current checks have been added for a good reason. Am I
> overlooking some important details that are not covered by the testsuite?
>
> Cheers,
> Harald van Dijk
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140116/1a457a7c/attachment.html>