Opaque types with resilience #22072

jckarter · 2019-01-23T23:42:45Z

A continuation of #21137. This branch adds "proper" resilience support. Opaque types can now enter the SIL type system, and will be able to be represented at runtime with opaque accessors for their associated metadata.

slavapestov · 2019-01-24T03:04:05Z

lib/Sema/TypeCheckGeneric.cpp

+    }
+  }
+
+  auto interfaceSignature = GenericSignature::get(interfaceGenericParams,


It might be cleaner if you use a GSB instead; then you can add a requirement with a class or any kind of existential in it and it will flatten it into the right thing. In particular, there's no guarantee that the order in which you're adding stuff above is the right order to get a canonical generic signature

slavapestov · 2019-01-24T03:04:41Z

lib/Sema/TypeCheckGeneric.cpp

+  }
+  auto opaqueTy = OpaqueTypeArchetypeType::get(opaqueDecl, subs);
+  auto metatype = MetatypeType::get(opaqueTy);
+  opaqueDecl->setInterfaceType(metatype);


The code for setting the type here is the same as in deserialization. Take a look at how NominalTypeDecl and AssociatedTypeDecl have computeType() methods; OpaqueTypeDecl should also have one.

slavapestov · 2019-01-24T03:05:08Z

lib/Sema/TypeCheckProtocolInference.cpp

@@ -1966,8 +1966,9 @@ auto AssociatedTypeInference::solve(ConformanceChecker &checker)
      if (replacement->hasDependentMember())
        return None;

-      if (replacement->hasArchetype())
+      if (replacement->hasArchetype()) {


Useless edit here

I thought LLVM style was always to brace if blocks. It's more maintainable regardless.

slavapestov · 2019-01-24T03:06:25Z

lib/Serialization/Deserialization.cpp

+                     getGenericSignature(interfaceSigID),
+                     getType(interfaceTypeID)->castTo<GenericTypeParamType>());
+    auto genericEnv = getGenericEnvironment(genericEnvID);
+    opaqueDecl->setGenericEnvironment(genericEnv);


For later: there's a mechanism to lazily deserialize generic environments. We do this already for generic functions and types; you might want to look into doing it here

slavapestov · 2019-01-24T03:07:31Z

lib/AST/ASTContext.cpp

+
+    auto replacementParam = replacement->getAs<GenericTypeParamType>();
+    if (!replacementParam)
+      llvm_unreachable("opaque types cannot currently be parameterized by non-identity type parameter mappings");


Nitpick: lines longer than 80 characters

slavapestov · 2019-01-24T03:08:21Z

lib/AST/ASTContext.cpp

+  auto opaqueInterfaceTy = Decl->getUnderlyingInterfaceType();
+  auto layout = signature->getLayoutConstraint(opaqueInterfaceTy);
+  auto superclass = signature->getSuperclassBound(opaqueInterfaceTy);
+  SmallVector<ProtocolDecl*, 4> protos;


Can you just do protos = signature->getConformsTo(opaqueInterfaceTy)?

slavapestov · 2019-01-24T03:09:02Z

lib/AST/ASTContext.cpp

+
+  // Create a generic environment and bind the opaque archetype to the
+  // opaque interface type from the decl's signature.
+  auto env = signature->createGenericEnvironment();


Possibly for later: can you lazily create the generic environment?

slavapestov · 2019-01-24T03:09:24Z

lib/AST/ASTContext.cpp

+                                               nullptr);
+  auto env = signature->createGenericEnvironment();
+  env->addMapping(signature->getGenericParams()[0], result);
+  result->Environment = env;


This is actually a regression. Can you lazily create the generic environment?

lib/AST/Decl.cpp

slavapestov · 2019-01-24T03:12:52Z

lib/AST/Type.cpp

+ReplaceOpaqueTypesWithUnderlyingTypes::operator()(CanType maybeOpaqueType,
+                                                 Type replacementType,
+                                                 ProtocolDecl *protocol) const {
+  auto abstractRef = ProtocolConformanceRef(protocol);


This is almost identical to the above

slavapestov · 2019-01-24T03:14:20Z

lib/AST/Type.cpp

+    if (!anyChanged)
+      return *this;
+
+    // FIXME: This re-looks-up conformances instead of transforming them in


Perhaps subst() should handle opaque types directly and transform() should not attempt the substitution here?

slavapestov · 2019-01-24T03:14:39Z

lib/AST/Type.cpp

+      return *this;
+    }
+
+    // Substitute the new root into the root of the interface type.


It feels like this should only need to happen in subst() too.

slavapestov · 2019-01-24T03:16:12Z

lib/SILGen/SILGenBuilder.cpp

@@ -156,6 +155,7 @@ InitExistentialValueInst *SILGenBuilder::createInitExistentialValue(

 InitExistentialMetatypeInst *SILGenBuilder::createInitExistentialMetatype(
    SILLocation loc, SILValue metatype, SILType existentialType,
+    CanType formalConcreteInstanceType,


Do you really need this? The instance type of a metatype is unlowered, so it should match the formal instance type.

It was necessary to support the hack of substituting out opaque types everywhere in SILGen, but I can back it out now.

slavapestov · 2019-01-24T03:16:50Z

lib/SILGen/SILGenExpr.cpp

+    return RValue(SGF, E, opaque);
+  }
+
+  // If the opaque type is loadable, emit the subexpression and bitcast it.


I wonder if opaque types should be more like existentials, with special instructions to project an address or wrap a loadable value...

We could add special instructions, but I don't know that it's worth it. The SIL passes already know how to deal with specializing bitcasts, and if we added specific instructions for underlying-to-opaque and the opposite conversion, they'd have to all be taught about those new instructions which are 99% semantically the same.

slavapestov · 2019-01-24T03:18:52Z

lib/Sema/CSSimplify.cpp

+      auto opaque1 = cast<OpaqueTypeArchetypeType>(desugar1);
+      auto opaque2 = cast<OpaqueTypeArchetypeType>(desugar2);
+
+      assert(!type2->is<LValueType>() && "Unexpected lvalue type!");


type1 and type2 will never be LValueType at this point, so you can remove the cargo cult

lib/Sema/CSSimplify.cpp

slavapestov · 2019-03-13T06:55:05Z

lib/IRGen/GenMeta.cpp

+    }
+
+    void addUnderlyingTypeAndConformances() {
+      auto underlyingType = Type(O->getUnderlyingInterfaceType())


Should this be a utility method on OpaqueTypeDecl?

…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

…9831658

… return types.

jckarter · 2019-04-18T17:15:42Z

@swift-ci Please test

jckarter · 2019-04-18T17:15:52Z

@swift-ci Please test source compatibility

swift-ci · 2019-04-18T17:19:49Z

Build failed
Swift Test OS X Platform
Git Sha - 577f14fe900015a7b2878080af7bfd98bbc5344a

swift-ci · 2019-04-18T17:24:34Z

Build failed
Swift Test Linux Platform
Git Sha - 577f14fe900015a7b2878080af7bfd98bbc5344a

jckarter · 2019-04-18T20:13:57Z

@swift-ci Please test Linux

slavapestov reviewed Jan 24, 2019

View reviewed changes

lib/AST/Decl.cpp Outdated Show resolved Hide resolved

slavapestov reviewed Jan 24, 2019

View reviewed changes

lib/AST/Decl.cpp Show resolved Hide resolved

slavapestov reviewed Jan 24, 2019

View reviewed changes

lib/Sema/CSSimplify.cpp Show resolved Hide resolved

slavapestov reviewed Jan 24, 2019

View reviewed changes

lib/Sema/CSSimplify.cpp Show resolved Hide resolved

jckarter force-pushed the opaque-type-runtime branch 3 times, most recently from a687a16 to 539efbf Compare February 4, 2019 19:35

jckarter force-pushed the opaque-type-runtime branch 2 times, most recently from 18b8153 to dece01a Compare February 12, 2019 20:32

jckarter force-pushed the opaque-type-runtime branch 5 times, most recently from 4bc5f1e to d749086 Compare February 26, 2019 19:15

slavapestov reviewed Mar 13, 2019

View reviewed changes

jckarter force-pushed the opaque-type-runtime branch from f002faf to 88a05b7 Compare March 15, 2019 03:53

jckarter added 21 commits April 17, 2019 14:44

change signature

cf00892

runtime interface fixup irgen

f363a10

Runtime: Implement entry points for opaque type support

a3c17bd

Decode opaque types in the runtime demangler.

95c43f4

add changelog entry for opaque types

4075749

Switch __opaque to some, per the latest rev of the proposal

be0140f

update tests

0b47f5b

fix rdar://problem/49230987

455f060

IRGen: Bind local metadata before emitting opaque type assoc type wit…

29a8c67

…nesses. rdar://problem/49585457

TBD: Include opaque type descriptors

733b08b

merge fixup

60aa49d

Relax some assertions to allow opaque-type values at global scope in …

78b4870

…scripts. rdar://problem/49818962

Serialization: Handle reentrance while deserializing OpaqueTypeDecl. …

f96ca72

…rdar://problem/49829836

Allow OpaqueTypeDecls to be (de)mangled as contexts, rdar://problem/4…

5bb22b0

…9831658

merge fixup

c58737f

Validate opaque return types for properties and subscripts.

59fd141

Check the underlying type of get-only computed properties with opaque…

0fcc7cd

… return types.

Serialize opaque return type of var/subscript decls.

b57f352

Visit var/subscript opaque return decls during IRGen/TBDGen.

a99716b

Track var/subscript opaque return decls for type reconstruction.

dbd3a48

jckarter force-pushed the opaque-type-runtime branch from c29dc4b to dbd3a48 Compare April 17, 2019 21:46

Demangler: Register substitution for opaque archetype manglings

b87a566

jckarter merged commit a8c2b50 into swiftlang:master Apr 18, 2019

AnthonyLatsis mentioned this pull request Apr 19, 2019

TypeChecker: consolidate func & subscript signature validation #24151

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Opaque types with resilience #22072

Opaque types with resilience #22072

jckarter commented Jan 23, 2019

slavapestov Jan 24, 2019

slavapestov Jan 24, 2019

slavapestov Jan 24, 2019

jckarter Jan 24, 2019

slavapestov Jan 24, 2019

slavapestov Jan 24, 2019

slavapestov Jan 24, 2019

slavapestov Jan 24, 2019

slavapestov Jan 24, 2019

slavapestov Jan 24, 2019

slavapestov Jan 24, 2019

slavapestov Jan 24, 2019

slavapestov Jan 24, 2019

jckarter Jan 24, 2019

slavapestov Jan 24, 2019

jckarter Jan 24, 2019

slavapestov Jan 24, 2019

slavapestov Mar 13, 2019

jckarter commented Apr 18, 2019

jckarter commented Apr 18, 2019

swift-ci commented Apr 18, 2019

swift-ci commented Apr 18, 2019

jckarter commented Apr 18, 2019

Opaque types with resilience #22072

Opaque types with resilience #22072

Conversation

jckarter commented Jan 23, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jckarter commented Apr 18, 2019

jckarter commented Apr 18, 2019

swift-ci commented Apr 18, 2019

swift-ci commented Apr 18, 2019

jckarter commented Apr 18, 2019