[cxx-interop] Enable addressable-self unconditionally #83289
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
Xazax-hun
requested review from
beccadax,
egorzhdan,
ian-twilightcoder,
jckarter and
zoecarver
as code owners
Xazax-hun
requested review from
fahadnayyar,
j-hui and
susmonteiro
as code owners
Xazax-hun
force-pushed
the
addressable-self-unconditional
branch
from
e380f53 to
a5900a2
Compare
jckarter
approved these changes
Jul 24, 2025
Xazax-hun
force-pushed
the
addressable-self-unconditional
branch
from
a5900a2 to
628d111
Compare
Xazax-hun
force-pushed
the
addressable-self-unconditional
branch
from
628d111 to
1891523
Compare
This was behind a feature flag. Unfortunately, this flag is viral, if the module we consume and the consuming module had inconsistent settings that could lead to deserialization errors. To avoid this, we need to move this out of the flag and apply the attribute unconditionally. This PR moves addressable-self out of the experimental flag and addresses a couple of the fallouts: * This attribute should not be applied to types with reference semantics like foreign reference types or Obj-C classes. * There was a SILGen assertion failure which is solved by pealing off the @lvalue specifier from the type behind a load expression. This fixes part of rdar://155971658
Xazax-hun
force-pushed
the
addressable-self-unconditional
branch
from
1891523 to
9525aee
Compare
Contributor
Author
|
@swift-ci please test |
Xazax-hun
pushed a commit
to Xazax-hun/swift
that referenced
this pull request
Aug 18, 2025
After swiftlang#83289 and swiftlang#82879 landed we should no longer get deserialization failures and this feature is no longer behind a flag. This patch also changes how we query if a function's return value depends on self. Previously, we queried the lifetime dependencies from the Swift declaration. Unfortunately, this is problematic as we might have not finished fully importing the types in the function signature just yet and the compiler might end up populating the conformance tables prematurely. To work this around, I store functions with self-dependent return values where lifetimes are computed in the importer for later use. The PR also adds a test to make sure the addressable dependency feature will not result in deserialization errors. rdar://155319311&154213694&112690482&128293252
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 was behind a feature flag. Unfortunately, this flag is viral, if the module we consume and the consuming module had inconsistent settings that could lead to deserialization errors. To avoid this, we need to move this out of the flag and apply the attribute unconditionally. This PR moves addressable-self out of the experimental flag and addresses a couple of the fallouts:
This fixes part of rdar://155971658