> On Aug 4, 2014, at 5:26 PM, Richard Smith <[email protected]> wrote:
>
> 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?
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
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
