[Sema] TypeWrappers: If type wrapper comes from .swiftinterface use synthesized decls
#62838
Conversation
|
@swift-ci please test |
| // if available. | ||
| { | ||
| auto parentSF = wrappedType->getDeclContext()->getParentSourceFile(); | ||
| if (parentSF && parentSF->Kind == SourceFileKind::Interface) { |
There was a problem hiding this comment.
I'm wondering if it's worth restricting this logic to swiftinterfaces. Could it be useful for the user to define custom implementations for the type wrapper's backing logic? Keeping a similar behavior between sources and swiftinterface would be nice too.
There was a problem hiding this comment.
This is something we intentionally don't want users to mess with.
xedin
force-pushed
the
type-wrappers-and-swiftinterfaces
branch
from
e5390f6 to
f99ea05
Compare
|
@swift-ci please test |
…faces Since type wrapper attributes could be applied to protocols and the protocol types could be used as existential values, it's not always possible to wrap all uses of feature into `#if $TypeWrappers` block so let's allow use of attributes if they come from a Swift interface file.
… synthesized decls Swift interfaces have both attribute and all publicly accessible synthesized members, which means that the synthesis needs to be taught to lookup existing synthesized declarations for `$storage`, `$Storage`, and `init(storageWrapper:)` if request comes for declaration that belongs to a Swift interface file.
…atch that of `$Storage`
The type is needed for serialization so it has to be requested and chached in type wrapper info.
xedin
force-pushed
the
type-wrappers-and-swiftinterfaces
branch
from
f99ea05 to
4f84d8a
Compare
|
@swift-ci please test |
| // RUN: -emit-module-path %t/PublicModule.swiftmodule \ | ||
| // RUN: -emit-module-interface-path %t/PublicModule.swiftinterface \ | ||
| // RUN: -emit-private-module-interface-path %t/PublicModule.private.swiftinterface \ | ||
| // RUN: -enable-experimental-feature TypeWrappers |
There was a problem hiding this comment.
Many of the tests that enable TypeWrappers seems to include REQUIRES: asserts. This test does not, and if one runs the test suite in a non-assert compiler, one gets the error "experimental feature 'TypeWrappers' cannot be enabled in a production compiler". Would it be correct adding REQUIRES: asserts also to this test?
Swift interfaces have both attribute and all publicly accessible
synthesized members, which means that the synthesis needs to be
taught to lookup existing synthesized declarations for
$storage,$Storage, andinit(storageWrapper:)if request comes fordeclaration that belongs to a Swift interface file.
Note that this PR also allows type wrappers if they appear in the
swiftinterface file because not all use situations could be detected
by
usesFeature*methods i.e. existential value uses of type wrappedprotocol.
Resolves: rdar://103425758