-
Notifications
You must be signed in to change notification settings - Fork 10.6k
[DiagnosticVerifier] Verify all diagnostics by default #84685
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
Merged
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
Member
Author
|
@swift-ci please smoke test |
This adds the implementation required for later changing the default behaviour of the -verify flag to error when diagnostics are emitted in buffers other than the main file and files added with -verify-additional-file. To keep the current behaviour, use the flag -verify-ignore-unrelated. This flag is added as a no-op so that tests can start using it before the new behaviour is enabled by default.
These are tests that fail in the next commit without this flag. This does not add -verify-ignore-unrelated to all tests with -verify, only the ones that would fail without it. This is NFC since this flag is currently a no-op.
This enables the previously added -verify-ignore-unrelated flag. When -verify is used without -verify-ignore-unrelated, diagnostics emitted in buffers other than the main file and those passed with -verify-additional-file (except diagnostics emitted at <unknown>:0) will now result in an error. They were previously ignored. The old behaviour is still available as opt-in using -verify-ignore-unrelated.
Member
Author
|
@swift-ci please smoke test |
Contributor
|
autodiff test changes LGTM |
Member
Author
|
@swift-ci please smoke test |
Member
Author
|
@swift-ci please smoke test |
Member
Author
|
Merging this to help figure out what's going on with Windows in #84642. Feel free to post-review! |
AnthonyLatsis
added a commit
that referenced
this pull request
Oct 17, 2025
[test] Fix 2 tests after #84685
dendiz
pushed a commit
to dendiz/swift
that referenced
this pull request
Oct 21, 2025
rdar://162273295
speednoisemovement
pushed a commit
to speednoisemovement/swift
that referenced
this pull request
Oct 29, 2025
rdar://162273295
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.
This adds the -verify-ignore-unrelated flag. When -verify is used without -verify-ignore-unrelated, diagnostics emitted in buffers other than the main file and those passed with -verify-additional-file (except diagnostics emitted at
<unknown>:0) will now result in an error. They were previously ignored. The old behaviour is still available as opt-in using -verify-ignore-unrelated, but by being strict by default it should make it harder to accidentally miss diagnostics.To avoid unnecessary performance overhead, -verify-additional-file is still required to parse the
expected-*directives in files other than the main file.Out of 4395 files using -verify, 404 required reverting to the old behaviour. I have not analysed the failures to decide whether adding
expected-*directives would be more suitable for each test. I simplyseded each file that failed with the new behaviour to restore the old one. But since they were already using the old behaviour there's at least no regression in test coverage.The bulk changes to the tests are in a separate commit. I recommend reviewing each commit separately.