[PATCH] Avoid a "diagnostic already in flight" assertion in diagnoseOdrViolations()

[Richard Smith]

On Mon, Aug 4, 2014 at 3:03 PM, Ben Langmuir <blangmuir at apple.com> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140804/40f42aba/attachment.html>