When running clangd, I found that occasionally, accessing a
precompiled header would cause an LLVM assertion to fire.
This in turn would cause a diagnostic to try and be emitted,
when the diagnostics machinery would reach back to find
information from the PCH, it would hit the same problem
that caused the initial assertion. Another assertion would fire and
another delayed diagnostic would be setup to report, and so on.
This recursive sequence would continue until stack overflow, which
would take down clangd.
This small patch works around that possibility by making a delayed
diagnostic more explicit (and therefore testable to avoid recursion).
I tested this against the files in our codebase that hit the
LLVM assertion with clangd and now the assertion clearly reports
and clangd is no longer exhausted by a stack overflow.
Tracking down the underlying problem (hitting the assertion)
is a separate task.
I'm not sure how (or if it's possible) to add a test that would
demonstrate the before/after here. Happy to take advice!
CurDelayedDiagID has a different kind of "in-flight" lifetime than CurDiagID. I think the comment here should be more explicit about what precisely the variable is doing, and perhaps it should have another name. Do we actually need the ID kept as state? If not, this would be simpler as:
Also, a couple of nit-picks: