Disable surprising lifetime inference of implicit initializers #82472
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
|
@swift-ci test |
|
Linux PR testing on main has been blocked all day |
|
@swift-ci smoke test linux |
1 similar comment
|
@swift-ci smoke test linux |
meg-gupta
approved these changes
Jun 25, 2025
I added a motivational example with explanation. |
|
@swift-ci smoke test |
1 similar comment
|
@swift-ci smoke test |
|
@swift-ci smoke test windows |
|
@swift-ci smoke test macOS |
|
This PR used to pass testing but now keeps failing with |
|
@swift-ci smoke test |
|
@swift-ci smoke test macOS |
1 similar comment
|
@swift-ci smoke test macOS |
Non-escapable struct definitions often have inicidental integer fields that are
unrelated to lifetime. Without an explicit initializer, the compiler would infer
these fields to be borrowed by the implicit intializer.
struct CountedSpan: ~Escapable {
let span: Span<Int>
let i: Int
/* infer: @Lifetime(copy span, borrow i) init(...) */
}
This was done because
- we always want to infer lifetimes of synthesized code if possible
- inferring a borrow dependence is always conservative
But this was the wrong decision because it inevitabely results in lifetime
diagnostic errors elsewhere in the code that can't be tracked down at the use
site:
let span = CountedSpan(span: span, i: 3) // ERROR: span depends on the lifetime of this value
Instead, force the author of the data type to specify whether the type actually
depends on trivial fields or not. Such as:
struct CountedSpan: ~Escapable {
let span: Span<Int>
let i: Int
@Lifetime(copy span) init(...) { ... }
}
This fix enables stricter diagnostics, so we need it in 6.2.
Fixes rdar://152130977 ([nonescapable] confusing diagnostic message when a
synthesized initializer generates dependence on an Int parameter)
|
@swift-ci smoke test |
|
@swift-ci smoke test windows |
1 similar comment
|
@swift-ci smoke test windows |
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.
Non-escapable struct definitions often have inicidental integer fields that are
unrelated to lifetime. Without an explicit initializer, the compiler would infer
these fields to be borrowed by the implicit intializer.
This was done because
But this was the wrong decision because it inevitabely results in lifetime
diagnostic errors elsewhere in the code that can't be tracked down at the use
site:
Instead, force the author of the data type to specify whether the type actually
depends on trivial fields or not. Such as:
This fix enables stricter diagnostics, so we need it in 6.2.
Fixes rdar://152130977 ([nonescapable] confusing diagnostic message when a
synthesized initializer generates dependence on an Int parameter)