And don't invalidate the VarDecl if the type is known.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/include/clang/Sema/Sema.h | ||
---|---|---|
3900 | not quite happy with the naming, open for suggestions. |
Very nice! Just want to give some thought to what these callsites look like.
clang/include/clang/Sema/Sema.h | ||
---|---|---|
3899 | This definitely seems like something that makes sense to call in more places. Wonder if the API can be smoother. Both of the examples are of the form: CorrectDelayedTypos, if invalid, rebuildTypos. | |
3900 | given current API, I'd suggest RecoverFromUncorrectedTypos or so |
clang/include/clang/Sema/Sema.h | ||
---|---|---|
3899 |
I think so (at least for the moment).
yeah, I think the eventual goal is to make the rebuild as the default fallback when typo correction fails, but it is still too far away to do it at the moment -- many testcases are broken (some are crashes, some are diagnostics improvements) when turning on recovery-ast by default. I suppose we'd need to fix that case by case until it is ready, given this situation, adding an option parameter (recoveryUncorrectedTypos) to CorrectDelayedTyposInExpr API seems a feasible solution. |
LG once the overload set is fixed
clang/include/clang/Sema/Sema.h | ||
---|---|---|
3873 | I think it's too confusing to have multiple overloads with different subsets of the parameters possible and also in different orders :-( If there's nothing better, you could replace this with two overloads CorrectDelayedTyposInExpr(ER, Filter) | |
clang/lib/Sema/SemaDecl.cpp | ||
12014 | could consider splitting this change out of the refactoring (or vice versa), up to you | |
clang/lib/Sema/SemaExprCXX.cpp | ||
8310 | /*RecoverUncorrectedTypos=*/ |
clang/include/clang/Sema/Sema.h | ||
---|---|---|
3873 | This method doesn't have too many usages, I'd just remove it, which leaves us two overloads (one for Expr, the other one for ExprResult). | |
clang/lib/Sema/SemaDecl.cpp | ||
12014 | split the refactoring change in https://reviews.llvm.org/D82047 |
I think it's too confusing to have multiple overloads with different subsets of the parameters possible and also in different orders :-(
If there's nothing better, you could replace this with two overloads
CorrectDelayedTyposInExpr(ER, Filter)
CorrectDelayedTyposInExpr(ER, bool, Filter)