infinite recursion.
Also guard against said infinite recursion by adding an assert that will
trigger if CorrectDelayedTyposInExpr is called before a previous call to
CorrectDelayedTyposInExpr returns (i.e. if the TreeTransform run by
CorrectDelayedTyposInExpr calls a sequence of methods that
end up calling CorrectDelayedTyposInExpr, as the new test case had done
prior to this commit). Fixes PR22292.
llvm-svn: 227368
Under certain circumstances, the identifier mentioned in the diagnostic
won't match the intended correction even though the replacement
expression and the note pointing to the decl are both correct.
Basically, the TreeTransform assumes the TypoExpr's Consumer points to
the correct TypoCorrection, but the handling of typos that appear to be
ambiguous from the point of view of TransformTypoExpr would cause that
assumption to be violated by altering the Consumer's correction stream.
This fix allows the Consumer's correction stream to be reset to the
right TypoCorrection after successfully resolving the percieved ambiguity.
Included is a fix to suppress correcting the RHS of an assignment to the
LHS of that assignment for non-C++ code, to prevent a regression in
test/SemaObjC/provisional-ivar-lookup.m.
This fixes PR22297.
llvm-svn: 227251
be corrected.
This fixes PR22250, which exposed the bug where if there's more than one
TypoExpr in the arguments, once one failed to be corrected none of the
TypoExprs after it would be handled at all thanks to an early return.
llvm-svn: 226624
ambiguity but wasn't.
In the new test case, "click" wasn't being corrected properly because
Sema::ClassifyName would call CorrectTypo for "click" then later
Sema::DiagnoseEmptyLookup would call CorrectTypoDelayed for the same use
of "click" (the former by the parser needing to determine what the
identifier is so it knows how to parse the statement, i.e. is it the
beginning of a declaration or an expression). CorrectTypo would record
that typo correction for "click" failed and CorrectTypoDelayed would see
that and not even try to correct the typo, even though in this case
CorrectTypo failed due to an ambiguity (both "Click" and "clock" having
an edit distance of one from "click") that could be resolved with more
information. The fix is two-fold:
1) Have CorrectTypo not record failed corrections if the reason for
the failure was two or more corrections with the same edit
distance, and
2) Make the CorrectionCandidateCallback used by
Parser::ParseCastExpression reject FunctionDecl candidates when the
next token after the identifier is a ".", "=", or "->" since
functions cannot be assigned to and do not have members that can be
referenced.
The reason for two correction spots is that from r222549 until r224375
landed, the first correction attempt would fail completely but the
second would suggest "clock" while having the note point to the
declaration of "Click".
llvm-svn: 226334
transform.
Also diagnose typos in the initializer of an invalid C++ declaration.
Both issues were hit using the same line of test code, depending on
whether the code was treated as C or C++.
Fixes PR22092.
llvm-svn: 225389
pessimistic about when to do so.
This also fixes PR21905 as the initialization argument was no longer
viewed as being type dependent due to the TypoExpr being type-cast.
llvm-svn: 224386
If there is more than one TypoExpr within the expr being transformed and
any but the last TypoExpr seen don't have any viable candidates, the
tree transform will be aborted early and the remaining TypoExprs are
never seen and hence never diagnosed. This adds a simple
RecursiveASTVisitor to find all of the TypoExprs to be diagnosed in the
case where typo correction of the entire expr fails (and the result of
the tree transform is an ExprError).
llvm-svn: 222465
This includes adding the new TypoExpr-based lazy typo correction to
LookupMemberExprInRecord as an alternative to the existing eager typo
correction.
llvm-svn: 220698
Kaelyn Takata