[4.2 EARLY] Fixes for batch mode diagnostics in Xcode #16530
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Make sure protocol witness errors don't leave the conformance context (cherry picked from commit 88169d6)
[Batch Mode] Suppressing diagnostics for non-primaries - rdar://40032762 (cherry picked from commit 46b8ad3)
…wiftlang#16521) The logic in 46b8ad3 to avoid putting certain diagnostics into serialized diagnostic files only makes sense if 1. every diagnostic emitted in file A.swift while processing a different file B.swift would be emitted if we processed A.swift on its own 2. we actually do process A.swift on its own in the same build, or have previously done an incremental build and produced the same diagnostic But the latter isn't actually guaranteed: if one batch job exits with a failure status, the driver will exit as well, assuming there's no point in continuing. Fortunately, we do have a flag that overrides this behavior, -continue-building-after-errors. (As noted in the patch, -continue-building-after-errors isn't *exactly* what we want. But it's conservatively correct.) (cherry picked from commit 606ee29)
|
@swift-ci Please test |
|
Build failed |
|
@swift-ci Please test Linux |
|
Also passed the source compat tests on the regular 4.2 branch in #16529. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Explanation: This is fallout from Wire up FileSpecificDiagnosticConsumer for serialized diagnostics #14900, which was the first attempt to deal with batch mode being different from single-file mode in terms of what diagnostics get produced and where. There was a hole in that scheme, however: if processing B.swift results in a diagnostic being emitted in A.swift (and B.swift and A.swift are in different batches), that diagnostic would appear in every file in the same batch as B.swift. This (1) looks bad in Xcode's Log Editor, and (2) could result in a diagnostic that never goes away. (How? Fix the problem in A.swift, and A.swift and B.swift will get rebuilt…but not necessarily other files in B.swift's original batch.)
These changes do three things:
Change Sema diagnostics so that every diagnostic emitted in file A.swift while processing a different file B.swift would be emitted if we processed A.swift on its own.
Implicitly turn on
-continue-building-after-errorswhen using batch mode to make sure we actually do process A.swift on its own in the same build. (A.swift might still not be processed if we're doing an incremental build, but that doesn't harm the model.)Stop emitting diagnostics located in A.swift altogether if A.swift isn't in the current batch.
Scope: Affects batch mode. (Also benignly tweaks some existing diagnostics in all modes.)
Issue: rdar://problem/40032762
Risk: Medium-high. We're choosing not to report some diagnostics in batch mode because we expect them to be reported elsewhere; if those assumptions are violated, users will not see these diagnostics at all, and will have to use either single-file or WMO instead.
Testing: Built a toy project and a real Apple project with the new compiler and observed the behavior of the Report Navigator for both warnings and errors.
Reviewed by: Me and @graydon (for @davidungar's change), @huonw and @DougGregor (for part of my changes), @davidungar (for the other part of my changes).