[cfe-dev] Explicit this expression in class template is dependent?

[Jason Haslam]

Okay, thanks for the explanation guys! I think I understand. I may try to propose a patch along those lines (construct MemberExpr in classes without dependent bases) if I find that I’m not too far out of my depth.

Jason


On Aug 22, 2014, at 2:23 PM, James Dennett <james.dennett at gmail.com> wrote:

> On Fri, Aug 22, 2014 at 12:56 PM, Jason Haslam <jason.haslam at gmail.com> wrote:
>> Hi all,
>> 
>> I find that explicit this expressions in class templates create a CXXDependentScopeMemberExpr in the AST while the equivalent implicit this is a MemberExpr. For example code like this:
>> 
>> template <typename T> struct A {
>>  int i;
>>  int getImplicit() { return i; } // MemberExpr
>>  int getExplicit() { return this->i; } // CXXDependentScopeMemberExpr
>> };
>> 
>> Why is explicit dependent? Is it technical (per the language standard) or an implementation detail? I’d like both expressions to resolve to the member for static analysis/refactoring/etc.
> 
> $ cat ct.cc
> 
> template <typename T> struct A {
>  int getExplicit() { return this->i; } // might compile
>  int getImplicit() { return i; } // must not compile
> };
> 
> $ clang++ -std=c++11 -c ct.cc
> ct.cc:4:30: error: use of undeclared identifier 'i'
>  int getImplicit() { return i; } // MemberExpr
>                             ^
> 1 error generated.
> 
> Lookup in "return i;" is done in phase one, when the template is
> parsed.  `i` isn't there, so it's an error.  Lookup in "return
> this->i;" is done in phase two, at template instantiation time.  If
> there were dependent base classes, "return this->i" could find things
> in them, while "return i" would not.
> 
> There is a rule that allows Clang to give an error for `getExplicit`
> also -- the rule that says that a template (/temploid) is ill-formed
> (no diagnostic required) if there is no possible well-formed
> instantiation of it.
> 
> It would also be convenient for tools if Clang became a little more
> aggressive in noticing that "return this->i" isn't dependent in any
> meaningful way in the code above, given that there are no dependent
> base classes.