NumTypos guard value ~0U doesn't prevent from creating new delayed typos. When
you create new delayed typos during typo correction, value ~0U wraps around to
0. When NumTypos is 0 we can miss some typos and treat an expression as it can
be typo-corrected. But if the expression is still invalid after correction, we
can get stuck in infinite loop trying to correct it.
Fix by not using value ~0U so that NumTypos correctly reflects the number of
typos.
rdar://problem/
38642201
Reviewers: arphaman, majnemer, rsmith
Reviewed By: rsmith
Subscribers: rsmith, nicholas, cfe-commits
Differential Revision: https://reviews.llvm.org/D47341
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@335638
91177308-0d34-0410-b5e6-
96231b3b80d8
if (E && !ExprEvalContexts.empty() && ExprEvalContexts.back().NumTypos &&
(E->isTypeDependent() || E->isValueDependent() ||
E->isInstantiationDependent())) {
- auto TyposInContext = ExprEvalContexts.back().NumTypos;
- assert(TyposInContext < ~0U && "Recursive call of CorrectDelayedTyposInExpr");
- ExprEvalContexts.back().NumTypos = ~0U;
auto TyposResolved = DelayedTypos.size();
auto Result = TransformTypos(*this, InitDecl, Filter).Transform(E);
- ExprEvalContexts.back().NumTypos = TyposInContext;
TyposResolved -= DelayedTypos.size();
if (Result.isInvalid() || Result.get() != E) {
ExprEvalContexts.back().NumTypos -= TyposResolved;
void overloadable_callexpr(int arg) {
func_overloadable(ar); //expected-error{{use of undeclared identifier}}
}
+
+// rdar://problem/38642201
+struct rdar38642201 {
+ int fieldName;
+};
+
+void rdar38642201_callee(int x, int y);
+void rdar38642201_caller() {
+ struct rdar38642201 structVar;
+ rdar38642201_callee(
+ structVar1.fieldName1.member1, //expected-error{{use of undeclared identifier 'structVar1'}}
+ structVar2.fieldName2.member2); //expected-error{{use of undeclared identifier 'structVar2'}}
+}