[PATCH] D50462: Try building complete AST after a fatal error was emitted if further diagnostics are expected

[Dmitry via Phabricator via cfe-commits]

Dmitry.Kozhevnikov added a comment.

When lookin through the list of the fatal errors, I think there are different categories:

1. "Scary" ones - "module was relocated", "invalid vfs overlay file", we probably shouldn't try to recover from it
2. "User" errors (include not found, too many errors) - we definitely shouldn't treat them as fatal in IDE
3. (subclass of the previous one): "something is too deep" (instantiations, brackets) - I'm afraid treating them as non-fatal right now would lead to a possibility of them happening again and again as we recover and proceed. So, in the future, the recovery might be more clever (i.e. going all the way up the instantiation/brackets stack, and then proceeding normally), however, while it's not done, I'm a bit uneasy demoting them from fatal.

So I'm preparing an alternative patch to demote "file not found" in include directive from the fatal error in .td file, and then immediately promote it back by default (but not in clangd).  WDYT?

In general, I find the whole concept of "Fatal error occurred/Uncompilable error occurred/Too many errors occurred/etc" too coarse-grained for tooling/IDEs. Parse/PP/Sema should probably try harder to recover, and not report such global state change. I'm not ready to approach it, though :)


Repository:
  rC Clang

https://reviews.llvm.org/D50462