Skip to content

[BatchMode] Fix interaction of bridging PCH and file specific diag consumer. #15452

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

graydon
Copy link
Contributor

@graydon graydon commented Mar 23, 2018

In batch mode, when using serialized diagnostics, we have a
FileSpecificDiagnosticConsumer splitting diags out to separate .dia files (one
per primary). This constructs a mapping from filenames to consumers when it's
first given a diag. So far so good.

It assumes, however, that there are source buffers to be found for each input
file it knows the name of. This is true -- and useful to assert -- once the
source buffers are set up. It's also a prerequisite for building the map it
uses to direct diags.

Unfortunately there's a small window between the consumer being built and the
source manager getting buffers, and in this window we attach to a bridging PCH.
If that attaching generates a diag of itself (say due to a bogus module map or
such) then the diag consumer is asked to build its map without source buffers.
The thing to do here is just to fall back to the "no mapping found" case; the
only tricky part is identifying when we're in that window of time. I've chosen
to use the approximating condition of "none of the file buffers exist at all".

@graydon graydon requested a review from jrose-apple March 23, 2018 08:00
@graydon
Copy link
Contributor Author

graydon commented Mar 23, 2018

@swift-ci please test

@swift-ci
Copy link
Contributor

Build failed
Swift Test Linux Platform
Git Sha - 53cd405162a36fb2093c711c83ccd856b6e3a475

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 53cd405162a36fb2093c711c83ccd856b6e3a475

@jrose-apple
Copy link
Contributor

Good catch!

Hm. I don't love the linear scan. Maybe we could check just the first file and assert that the rest are the same?

@graydon
Copy link
Contributor Author

graydon commented Mar 23, 2018

@jrose-apple I guess; not terribly wedded to it but I will note that the existing code (computeConsumersOrderedByRange) treats "first file is unknown" as an error condition (assert-fail / crash in non-assert), and this is what motivated the change here. So if I catch that a layer higher up and treat it as a fallback-able condition, the inner assert will always hold.

@jrose-apple
Copy link
Contributor

I'm sorry, I meant that instead of your call to std::none_of, outside computeConsumersOrderedByRange, you'd just check the first buffer name there, assert the std::none_of thing there, and then return null.

@graydon graydon force-pushed the batch-mode-pch-attach-diagnostic-multiplexing branch from 53cd405 to 3d76cd5 Compare March 24, 2018 01:04
@graydon
Copy link
Contributor Author

graydon commented Mar 24, 2018

@jrose-apple pushed update with that change (along with fix to linux, which lacks @import)

// can't find buffers for the inputs).
if (!(SubConsumers.empty() ||
SM.getIDForBufferIdentifier(SubConsumers.begin()->first).hasValue())) {
assert(std::none_of(SubConsumers.begin(), SubConsumers.end(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpick: llvm::none_of makes this simpler!

// than trying to build a nonsensical map (and actually crashing since we
// can't find buffers for the inputs).
if (!(SubConsumers.empty() ||
SM.getIDForBufferIdentifier(SubConsumers.begin()->first).hasValue())) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Honestly if SubConsumers is empty we're in trouble anyway. We may as well assert that so that we don't drop diagnostics on the floor. (This is good too because I find this if-condition hard to read.)

…nsumer.

In batch mode, when using serialized diagnostics, we have a
FileSpecificDiagnosticConsumer splitting diags out to separate .dia files (one
per primary). This constructs a mapping from filenames to consumers when it's
first given a diag. So far so good.

It assumes, however, that there are source buffers to be found for each input
file it knows the name of. This is true -- and useful to assert -- once the
source buffers are set up. It's also a prerequisite for building the map it
uses to direct diags.

Unfortunately there's a small window between the consumer being built and the
source manager getting buffers, and in this window we attach to a bridging PCH.
If that attaching generates a diag of itself (say due to a bogus module map or
such) then the diag consumer is asked to build its map without source buffers.
The thing to do here is just to fall back to the "no mapping found" case; the
only tricky part is identifying when we're in that window of time. I've chosen
to use the approximating condition of "none of the file buffers exist at all".
@graydon graydon force-pushed the batch-mode-pch-attach-diagnostic-multiplexing branch from 3d76cd5 to 689663d Compare March 24, 2018 03:24
@graydon
Copy link
Contributor Author

graydon commented Mar 24, 2018

@jrose-apple nits addressed (hopefully)!

Copy link
Contributor

@jrose-apple jrose-apple left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@graydon
Copy link
Contributor Author

graydon commented Mar 24, 2018

@swift-ci please test and merge

2 similar comments
@graydon
Copy link
Contributor Author

graydon commented Mar 24, 2018

@swift-ci please test and merge

@graydon
Copy link
Contributor Author

graydon commented Mar 24, 2018

@swift-ci please test and merge

@graydon
Copy link
Contributor Author

graydon commented Mar 24, 2018

@swift-ci please test

@graydon
Copy link
Contributor Author

graydon commented Mar 24, 2018

@swift-ci please test and merge

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 53cd405162a36fb2093c711c83ccd856b6e3a475

@swift-ci
Copy link
Contributor

Build failed
Swift Test Linux Platform
Git Sha - 53cd405162a36fb2093c711c83ccd856b6e3a475

@graydon
Copy link
Contributor Author

graydon commented Mar 24, 2018

@swift-ci please smoke test OSX platform

1 similar comment
@graydon
Copy link
Contributor Author

graydon commented Mar 24, 2018

@swift-ci please smoke test OSX platform

@graydon
Copy link
Contributor Author

graydon commented Mar 24, 2018

@swift-ci please smoke test

@graydon
Copy link
Contributor Author

graydon commented Mar 24, 2018

@swift-ci please test OSX platform

@graydon
Copy link
Contributor Author

graydon commented Mar 24, 2018

@swift-ci please test

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 689663d

@graydon
Copy link
Contributor Author

graydon commented Mar 24, 2018

@swift-ci please test

1 similar comment
@graydon
Copy link
Contributor Author

graydon commented Mar 24, 2018

@swift-ci please test

@graydon graydon merged commit 56a2a97 into swiftlang:master Mar 25, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants