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



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to