[PATCH] Avoid a "diagnostic already in flight" assertion in diagnoseOdrViolations()
richard at metafoo.co.uk
Mon Aug 4 17:26:14 PDT 2014
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...
More information about the cfe-commits