On Mon, Aug 4, 2014 at 3:03 PM, Ben Langmuir <[email protected]> wrote:
> Hi Richard, > > We have several lazy builtin Decls (for ObjC decls, va_list, etc.) that > might get filled in when we desugar a type for the ODR diagnostics, and > these may deserialize more content from a module when they lookup an > IdentifierInfo, leading to trying to emit a diagnostic while a diagnostic > is already in flight. Hmm, thinking more about the specific problem here, I wonder if even the approaches we've discussed so far are not enough. In particular, suppose we hit this diagnostic: Diag(...) << D->somethingThatTriggersDeserialization() In this case, we'll again assert when deserialization issues a diagnostic with another diagnostic in flight. Some quick grepping was unable to find such a case, but I feel uneasy about this possibility; this seems like a time bomb. Maybe ASTReader should buffer all of its diagnostics, and emit them at some known-safe point in time, such as end of TU. What do you think?
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
