On 16/01/2014 06:38, Harald van Dijk wrote:
Ah, thanks, you're right. If the in-class declaration doesn't use
'this', but the definition does, then 'this' would not be diagnosed with
my approach.
Hi Harald,
If you have the time could you throw together a couple of tests for
those cases as well?
checkThisInStaticMemberFunctionAttributes() looks like it can be dropped
now that RecursiveASTVisitor visits attributes (r198224) so I'm hopeful
we can still apply the bulk of the cleanup from your original patch
without regressing.
Alp.
Normally, if the definition does, so would the in-class
declaration, where it would be diagnosed, but an example of where it
doesn't is
struct Foo {
static bool f();
};
auto Foo::f() -> decltype(this != 0) {
return true;
}
Cheers,
Harald van Dijk
On 16/01/14 01:25, Richard Smith wrote:
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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
http://lists.cs.uiuc.edu/__mailman/listinfo/cfe-commits
<http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits>
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
--
http://www.nuanti.com
the browser experts
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
