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

[Ben Langmuir]

> On Aug 4, 2014, at 5:26 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> 
> 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?

It looks like a lot of ASTReader is sort of doing that already by using the 1-item buffer from Diags.setDelayedDiagnostic() and just discarding any diagnostics after the first one.  The “safe point” in this case is immediately when there is no in-flight diag, or whenever the in-flight diagnostic is emitted if there is.  This is probably better than waiting until the end of the TU, as it maintains the order of the diagnostics.  Right now this single delayed diagnostic is limited to <= 2 arguments, which must be StringRefs, but this could always be extended...

That being said, I don’t know that we necessarily *want* non-fatal errors to be emitted if they are encountered while a diagnostic is in flight.  I think I’d need to see a specific example before I could say.  Maybe as a first pass, we can make all ASTReader diagnostics that can occur during deserialization not emit at all when Diags.isDiagnosticInFlight() == true?

Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140804/867e8d00/attachment.html>