resolved the -> to a call to a specific operator-> function. The particular
test case added here is actually being mishandled: the implicit member access
should not be type-dependent (because it's accessing a non-type-dependent
member of the current instantiation), but calls to a type-dependent operator->
that is a member of the current instantiation would be liable to hit the same
codepath.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284999
91177308-0d34-0410-b5e6-
96231b3b80d8
if (S->isTypeDependent()) {
// Type-dependent operator calls are profiled like their underlying
// syntactic operator.
+ //
+ // An operator call to operator-> is always implicit, so just skip it. The
+ // enclosing MemberExpr will profile the actual member access.
+ if (S->getOperator() == OO_Arrow)
+ return Visit(S->getArg(0));
+
UnaryOperatorKind UnaryOp = UO_Extension;
BinaryOperatorKind BinaryOp = BO_Comma;
Stmt::StmtClass SC = DecodeOperatorCall(S, UnaryOp, BinaryOp);
S< S<w>::cond && 1 > foo();
};
+ struct Arrow { Arrow *operator->(); int n; };
+ template<typename T> struct M {
+ Arrow a;
+ auto f() -> M<decltype(a->n)>;
+ };
+
struct Alien;
bool operator&&(const Alien&, const Alien&);
template <bool w>
S< S<w>::cond && 1 > N::foo() { }
+
+ template<typename T>
+ auto M<T>::f() -> M<decltype(a->n)> {}
}
namespace PR7460 {