<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 4, 2014 at 3:03 PM, Ben Langmuir <span dir="ltr"><<a href="mailto:blangmuir@apple.com" target="_blank">blangmuir@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Richard,<br>
<br>
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.</blockquote>
<div><br></div><div>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:</div><div><br></div><div>Diag(...) << D->somethingThatTriggersDeserialization()</div>
<div><br></div><div>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?</div>
</div></div></div>