Commit Graph

2 Commits

Author SHA1 Message Date
Ilya Biryukov aeae71cd96 [Sema] Emit diagnostics for uncorrected delayed typos at the end of TU
Summary:
Instead of asserting all typos are corrected in the sema destructor.

The sema destructor is not run in the common case of running the compiler
with the -disable-free cc1 flag (which is the default in the driver).

Having this assertion led to crashes in libclang and clangd, which are not
reproducible when running the compiler.

Asserting at the end of the TU could be an option, but finding all
missing typo correction cases is hard and having worse diagnostics instead
of a failing assertion is a better trade-off.

For more discussion on this, see:
https://lists.llvm.org/pipermail/cfe-dev/2019-July/062872.html

Reviewers: sammccall, rsmith

Reviewed By: rsmith

Subscribers: usaxena95, dgoldman, jkorous, vsapsai, rnk, kadircet, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D64799

llvm-svn: 374152
2019-10-09 10:00:05 +00:00
Volodymyr Sapsai 31f7c4aa77 [Parser] Avoid correcting delayed typos in array subscript multiple times.
We correct some typos in `ActOnArraySubscriptExpr` and
`ActOnOMPArraySectionExpr`, so when their result is `ExprError`, we can
end up correcting delayed typos in the same expressions again. In
general it is OK but when `NumTypos` is incorrect, we can hit the
assertion

> Assertion failed: (Entry != DelayedTypos.end() && "Failed to get the state for a TypoExpr!"), function getTypoExprState, file clang/lib/Sema/SemaLookup.cpp, line 5219.

Fix by replacing some subscript `ExprResult` with typo-corrected expressions
instead of keeping the original expressions. Thus if original expressions
contained `TypoExpr`, we'll use corrected expressions instead of trying to
correct them again.

rdar://problem/47403222

Reviewers: rsmith, erik.pilkington, majnemer

Reviewed By: erik.pilkington

Subscribers: jkorous, dexonsmith, cfe-commits

Differential Revision: https://reviews.llvm.org/D60848

llvm-svn: 359713
2019-05-01 19:24:50 +00:00