Fix LifetimeDependenceDiagnostics to ignore closure captures #72635
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
This fixes bugs when ~Escapable types depended on values that are passed to 'consume'. The consume operator diagnostics are broken when dependent values are present. This sidesteps the problem for lifetime dependence. And we generally want to diagnose lifetime dependence after all move-only related diagnostics. That way, using a dependent value after consume provides a more informative diagnostic about the dependent value and its scope.
Emitting a note with an invalid source location is actively harmful. It confuses users and tools, makes it impossible to write unit tests. In this case, the note simply says "use here", so it's completely free of information without the source location.
ClosureLifetimeFixup now emits mark_dependence [nonescaping]. Those should be ignored by diagnostics. In the capture case, the dependence has already been resolved, and may not match the SIL patterns that we expect for source-level lifetime dependencies. Fixes rdar://125375685 ([nonescapable] Fix lifetime-dependence diagnostics in the stdlib)
-enable-experimental-feature NonescapableTypes now only controls syntax and some type inferrence features.
|
@swift-ci test |
|
@swift-ci benchmark |
|
@swift-ci test source compatibility |
atrick
commented
Mar 27, 2024
| // | ||
| // FIXME: why is DeinitDevirtualizer in the middle of the mandatory pipeline, | ||
| // and what passes/compilation modes depend on it? This pass is never executed | ||
| // or tested without '-Xllvm enable-deinit-devirtualizer'. |
There was a problem hiding this comment.
@eeckstein if you know why the DeinitDevirtualizer runs in the middle of the mandatory pipeline or know of any passes that depend on it, in embedded mode or otherwise, please document that in the pass header. I couldn't figure it out after wasting an hour investigating.
|
@swift-ci Please Build Toolchain macOS Platform |
|
source compat Siesta appears to be failing on main also |
This was referenced Mar 28, 2024
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.
Fix LifetimeDependenceDiagnostics to ignore closure captures
ClosureLifetimeFixup now emits mark_dependence [nonescaping]. Those should be
ignored by diagnostics. In the capture case, the dependence has already been
resolved, and may not match the SIL patterns that we expect for source-level
lifetime dependencies.
Fixes rdar://125375685 ([nonescapable] Fix lifetime-dependence diagnostics in the stdlib)x
This allows us to always-enable lifetime-depenence diagnostics.
This PR also includes obvious, harmless fixes to move-only diagnostics to allow adding
nonescapable unit tests.
Fix MoveOnlyDiagnostics, ConsumOperator...Checkers diagnostics
Emitting a note with an invalid source location is actively
harmful. It confuses users and tools, makes it impossible to write
unit tests. In this case, the note simply says "use here", so it's
completely free of information without the source location.