[5.1 04-24-2019] Opaque result types, SE-244 #24282
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
To represent the abstracted interface of an opaque type, we need a generic signature that refines the outer context generic signature with an additional generic parameter representing the underlying type and its exposed constraints. Opaque types also need to be keyed by their originating decl, so that we can treat values of the same opaque type as the same. When we check a FuncDecl with an opaque type specified as its return type, create an OpaqueTypeDecl and associate it with the originating decl. (A representation for *types* derived from the opaque decl will come next.)
It's currently meaningless, and it'll require thought to pass the correct value when it becomes meaningful.
…lt types. This prevents opaque result types from propagating nontrivially into other declarations' types, which may be confusing and create implementation complexities.
Tear out the hacks to pre-substitute opaque types before they enter the SIL type system. Implement UnderlyingToOpaqueExpr as bitcasting the result of the underlying expression from the underlying type to the opaque type.
Introduce code to emit runtime calls to get the type metadata for the underlying type of an opaque type and to get its conformances.
… for associated types.
…nesses. rdar://problem/49585457
When printing a swiftinterface, represent opaque result types using an attribute that refers to the mangled name of the defining decl for the opaque type. To turn this back into a reference to the right decl's implicit OpaqueTypeDecl, use type reconstruction. Since type reconstruction doesn't normally concern itself with non-type decls, set up a lookup table in SourceFiles and ModuleFiles to let us handle the mapping from mangled name to opaque type decl in type reconstruction. (Since we're invoking type reconstruction during type checking, when the module hasn't yet been fully validated, we need to plumb a LazyResolver into the ASTBuilder in an unsightly way. Maybe there's a better way to do this... Longer term, at least, this surface design gives space for doing things more the right way--a more request-ified decl validator ought to be able to naturally lazily service this request without the LazyResolver reference, and if type reconstruction in the future learns how to reconstruct non-type decls, then the lookup tables can go away.)
…scripts. rdar://problem/49818962
…rdar://problem/49829836
…dar://problem/50005972
…sions In protocol extensions, and in the future parameterized extensions, have their own generic arguments independent of an originating nominal type's formal generic parameters. Instead of crashing, handle this gracefully. rdar://problem/50038754
Fix a trio of issues involving mangling for opaque result types: * Symbolic references to opaque type descriptors are not substitutions * Mangle protocol extension contexts correctly * Mangle generic arguments for opaque result types of generic functions The (de-)serialization of generic parameter lists for opaque type declarations is important for the last bullet, to ensure that the mangling of generic arguments of opaque result types works across module boundaries. Fixes the rest of rdar://problem/50038754.
|
@swift-ci Please test |
|
@swift-ci Please test source compatibility |
|
The compatibility suite failures look like a configuration issue with the bot, since everything is failing with things like: |
AnnaZaks
approved these changes
Apr 25, 2019
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.
No description provided.