<div dir="ltr"><div>Hello folks, </div><div><br></div><div>Given the following case:</div><div><br></div><div>void free();<br></div><div>void test() {</div><div>   if (!force) {} // diagnostic 1:  use of undeclared identifier 'force'; did you mean 'free'?</div><div>                     // diagnostic 2:  warning: address of function 'free' will always evaluate to 'true'</div><div>}</div><div><br></div><div>The secondary diagnostic seems to be bogus, and it doesn't reflect the written source code, which can easily cause confusions. My idea is to use a dependent RecoveryExpr (which wraps the typo-correct AST node) to suppress all secondary diagnostics.</div><div><br></div><div>I have a prototype at <a href="https://reviews.llvm.org/D90459" target="_blank">https://reviews.llvm.org/D90459</a>. I see some improvements, but there are some regressions as well:</div><div><br></div><div>Improvements</div><div>- the resulting AST look better because the error is visible in the AST (with RecoveryExpr node)</div><div>- we emit more typo corrections for more cases, see <a href="https://reviews.llvm.org/differential/changeset/?ref=2240247" target="_blank">[1]</a>, <a href="https://reviews.llvm.org/differential/changeset/?ref=2240248" target="_blank">[2]</a></div><div><br></div><div>Regressions</div><div>- recursive/nested typo corrections, e.g. `TypoX.TypoY;`, we emit just 1 typo-correction while the old behavior emits two, see <a href="https://reviews.llvm.org/differential/changeset/?ref=2240254" target="_blank">[1]</a></div><div></div><div>- ambiguous typos, when there are ambiguous typo candidates (they have the same edit distance), the old one seems to perform better in some cases, see<a href="https://reviews.llvm.org/differential/changeset/?ref=2240246" target="_blank"> [1]</a></div><div>- other misc regressions, I think we could fix them</div><div><br></div><div>The secondary diagnostics are not wrong from the AST perspective, but they seem to be unnecessary. In clangd, we'd like to suppress all secondary diagnostics, but I'm not sure this is a right choice for clang.</div><div><br></div><div>What do people think?</div><div><br></div><div><br></div><div>Thanks,</div><div>Haojian</div><div><br></div></div>