[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.

In https://reviews.llvm.org/D50462#1203038, @vsapsai wrote:

> Have you checked that produced AST is of sufficient quality to be used? Because, for example, for invalid code error recovery tries to keep going but the end result isn't always good.
>  In the test you verify that you can ignore bogus includes. Is this the real-world use case you want to address? Or something like "stddef.h not found"?


I'm assuming it should help when the recovery is good enough (e.g. when the symbols from the missing header are used rarely, or only used inside function bodies). For the case like "`stddef.h` not found" there is a chance that resulting AST wouldn't be too useful, however, for IDE-like tasks, where we usually want to get as much info from the incomplete code as possible, it's not too bad IMO (comparing to just disabling all IDE features altogether after a missing include).

The only required property is that the resulting issues shouldn't be catastrophic (further processing shouldn't crash or hang), however, it would be a separate issue - after all, you always can remove the include directive in question.

The main use case I have is that it's inconvenient to browse or edit code in clang-based IDEs when either:

- there is a typo in an include directive somewhere (e.g. because I'm still modifying the code, moving files around, etc)
- there is a missing/misconfigured 3rd-party dependency. Obviously, the code is not supposed to compile, however, I'd expect e.g. "Goto Declaration" still work for unrelated code, assuming it recovered properly, which, in my anecdotical experience, it usually does
- (a very specific use case I'm often hitting) you often have missing includes when you browse llvm/clang code base and haven't built some part of it, so you don't have generated headers. The parser usually recovers very well in this case, if not for these two cut-offs I'm changing in this patch


Repository:
  rC Clang

https://reviews.llvm.org/D50462