Parsing after #include failure

We continue parsing after #include failures, as does gcc. Is this
really a good design decision? I understand that it may be useful
in some cases (actually I can't think of ones I consider major). In
many common cases this just results in a cascade of type errors,
with the root cause left at the top.

Has this been discussed? Is there a good argument for this
behavior? If we wanted to report the entire set of include failures
I could understand continuing to lex but shutting down Sema.

- Daniel

FWIW I'd like this behavior. There's nothing like eighteen bajillion
error messages that end up with "oh, i forgot to #include "MyDumbType.h""

-eric

We continue parsing after #include failures, as does gcc. Is this
really a good design decision? I understand that it may be useful
in some cases (actually I can't think of ones I consider major). In
many common cases this just results in a cascade of type errors,
with the root cause left at the top.

Has this been discussed?

Nope.

Is there a good argument for this
behavior?

Not really. Seems easy to try. It would also be interesting to see what other compilers do. The lightspeed C compiler would only emit one error at a time (pretty radical)...made the job of recovery a non issue.

I've actually been interested in trying to solve the opposite problem (though it's *much* harder). I'd love a compiler (or IDE) that could do a fuzzy parse and make suggestions on what includes I've missed! On Mac OS X, developers workaround this by including very coarse grain framework headers that import the world. This isn't the "culture" in llvm/clang, however.

snaroff