Preliminary Sema and AST support for subclass existentials (SE-0156) #8650

slavapestov · 2017-04-09T11:26:54Z

Work in progress.

TODO:

If a class C conforms to P, then C & P should be the same type as C. While we can convert back and forth, they currently appear as distinct types for purposes of overloading, etc.
If a class C is a subclass of D, the proposal says C & D should be equivalent to D; for now, it is an error. C & C is equivalent to C, though.
Type alias lookup on a subclass existential is not quite right if the typealias is a member of a protocol that the superclass conforms to concretely.
Protocol inheritance clauses cannot contain superclasses yet.
AnyObject is not yet lowered away completely.
Mangling, SILGen, IRGen, serialization, runtime support.
Importing Objective-C subclass existentials.

DougGregor · 2017-04-10T17:24:14Z

include/swift/AST/ExistentialLayout.h

+
+  /// Whether the existential requires a class, either via an explicit
+  /// '& AnyObject' member or because of a superclass or protocol constraint.
+  bool requiresClass : 1;


Should this more generally have a LayoutConstraintKind ?

DougGregor · 2017-04-10T17:30:38Z

lib/AST/Type.cpp

+
+  auto members = type->getProtocols();
+  if (!members.empty() &&
+      isa<ClassDecl>(members[0]->getAnyNominal())) {


getClassOrBoundGenericClass() would be slightly more direct.

That doesn't support UnboundGenericType, which is possible here.

DougGregor · 2017-04-10T17:37:09Z

lib/AST/Decl.cpp

+        // Only protocols can appear in the inheritance clause
+        // of a protocol -- anything else should get diagnosed
+        // elsewhere.
+        if (auto *protoTy = type->getAs<ProtocolType>()) {


Wait, really? I thought we could have typealiases of protocol compositions, as well as superclass types, in this list?

I'll add more tests and see what we support exactly.

DougGregor · 2017-04-10T17:37:52Z

lib/AST/ASTContext.cpp

  for (Type t : Protocols) {
    if (!t->isCanonical())
      isCanonical = false;
+    properties |= t->getRecursiveProperties();
  }

  // Create a new protocol composition type.
  ProtocolCompositionType *New
    = new (C, AllocationArena::Permanent)


Wrong arena! You'll need to compute the arena based on the recursive properties.

Good point, thanks!

I just wanted to give @jrose-apple another fun memory smasher bug to track down :)

Just think of how much time we saved with this one little bit of code review.

DougGregor · 2017-04-10T17:38:40Z

lib/AST/GenericSignatureBuilder.cpp

+           "explicit AnyObject not yet supported");
+
+    if (layout.superclass) {
+      if (addSuperclassRequirementDirect(subjectPA, layout.superclass,


Thanks for fixing me FIXME.

…substitutions This allows always using the constructor that takes substitutions, passing in an empty list if there are none.

This allows calling simplifyType() unconditionally even if we know we don't have any type variables in the type.

Don't pass in the opened type; instead have the caller call simplifyType() if needed. Also, make computeSubstitutions() bail out if there's no generic signature, which allowed unifying several generic vs non-generic code paths. Hopefully there is enough short circuiting in there now that we're not doing any extra work in the non-generic case.

Now that we no longer map dependent member types to fresh type variables, the keys in the replacement map can just be GenericTypeParamTypes.

…ed 'Self' A protocol extension can add additional generic constraints on 'Self' or associated types thereof. In particular, 'Self' itself can have a superclass constraint placed on it. There were a couple of problems with this corner case: - Type aliases defined in protocols that 'Self' conforms to _as a concrete type_ to were not handled properly, triggering an assertion. For example, protocol P { typealias T = ... } class C : P {} protocol Q {} extension Q where Self : C { ... T ... } The conformance o P comes from the 'Self : C' constraint. - If the type was found in a superclass of 'Self', we used the wrong base type for the substitution. For example, protocol P {} class C<T> { typealias A = T } class D : C<Int> {} extension P where Self : D { ... A ... } The substituted type of 'A' should be computed with a self type of C<Int> here. Also, take another stab at cleaning up the mess that is resolveTypeInContext() and related bits of code.

…trained archetype This hits the FIXME case in CompleteGenericTypeResolver's resolveDependentMemberType() method I thought was dead, but it's actually not.

This consolidates calculations which need to look at every protocol in an existential type. Soon we will also have to deal with superclass constrained existentials, so start updating call sites that look at all protocols to use the new ExistentialLayout and correctly handle a class constraint as well. Also, eventually I will kill off the AnyObject protocol and model it as a protocol composition with no protocols or superclass, but the requiresClass() flag set. This is not quite modeled this way yet and AnyObject still exists, but the new abstraction is a step in the right direction.

Don't assume all members are existential types; we could have a class (or a class-constrained existential) also, and this needs to be handled. When building a canonical protocol composition, the subclass requirement always comes first in the list of types. This is an important invariant allowing ExistentialLayout to be calculated quickly. Also, calculate the recursive properties of the composition type from the recursive properties of its members, since they're no longer trivial if the composition contains a class member with generic parameters.

…stentials Whether a protocol composition requires a class is no longer solely a property of what protocols it contains; now, a protocol composition consisting of a non-class constrained protocol and a superclass should return true from requiresClass(). This is done by looking at the ExistentialLayout, instead of walking the members directly.

The "superclass" of a subclass existential is the superclass constraint. This makes a bunch of random things work, but is somewhat unprincipled. It fits with how we already handle class-constrained archetypes and DynamicSelfType, though.

This function takes a member of a class and a base type, and returns the correct 'self' type to substitute into the member's type. When accessing a member of a subclass existential, if the member was found via the superclass constraint, we have to erase the existential down to the class type to calculate the member's substituted type. We already had special logic to handle class-constrained archetypes in the callers of getSuperclassForDecl(); move this check into the method, and add a similar check for subclass existentials, which now support the getSuperclass() method.

If the member came from a class, we're not going to substitute the 'Self' type. Instead, we open the existential, upcast the archetype up to the class type and access the member as if it were a class member in the usual way.

…entials

If the -enable-experimental-subclass-existentials staging flag is on, resolveType() now allows protocol compositions to contain class types. It also diagnoses if a composition has more than one superclass requirement. Also, change diagnostics that talked about 'protocol composition' to 'protocol-constrained type'. Since such types can now contain a superclass constraint, it's not correct to call them protocol composition. "Protocol-constrained type" isn't quite accurate either because 'Any' has no protocols, and 'AnyObject' will have no protocols but a general class constraint; but those are edge cases which won't come up in these diagnostics.

slavapestov · 2017-04-11T00:11:40Z

@swift-ci Please smoke test

slavapestov force-pushed the subclass-existentials branch 3 times, most recently from 6996814 to 3e8bb89 Compare April 10, 2017 08:29

DougGregor reviewed Apr 10, 2017

View reviewed changes

slavapestov added 19 commits April 10, 2017 17:04

AST: Add an assertion to MemberRefExpr constructor

b9494b0

AST: Do the right thing when constructing ConcreteDeclRef with empty …

efb3d42

…substitutions This allows always using the constructor that takes substitutions, passing in an empty list if there are none.

Sema: Remove unused method declaration

143c91a

Sema: Fix a compiler crasher

011fb81

Sema: simplifyType() can return early if the type has no variables

6b4c877

This allows calling simplifyType() unconditionally even if we know we don't have any type variables in the type.

Sema: Better type safety for opened types map

819dfd5

Now that we no longer map dependent member types to fresh type variables, the keys in the replacement map can just be GenericTypeParamTypes.

Sema: Test inheritance clause references to nested type of class-cons…

95e2802

…trained archetype This hits the FIXME case in CompleteGenericTypeResolver's resolveDependentMemberType() method I thought was dead, but it's actually not.

AST: Update GenericSignatureBuilder for subclass existentials

d7c1d81

AST: Update TypeBase::mayHaveSuperclass() for subclass existentials

b1d22ff

Sema: Update constraint solver for subclass existentials

2e5b3b6

Sema: Update TypeChecker::checkInheritanceClause() for subclass exist…

1b2252f

…entials

slavapestov force-pushed the subclass-existentials branch from 3e8bb89 to 143c29e Compare April 11, 2017 00:06

slavapestov force-pushed the subclass-existentials branch from 143c29e to de323b5 Compare April 11, 2017 00:11

slavapestov merged commit a5fd009 into swiftlang:master Apr 11, 2017

slavapestov mentioned this pull request Apr 12, 2017

Preliminary SILGen support for subclass existentials (SE-0156) #8685

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Preliminary Sema and AST support for subclass existentials (SE-0156) #8650

Preliminary Sema and AST support for subclass existentials (SE-0156) #8650

Uh oh!

slavapestov commented Apr 9, 2017 •

edited

Loading

Uh oh!

DougGregor Apr 10, 2017

Uh oh!

DougGregor Apr 10, 2017

Uh oh!

slavapestov Apr 10, 2017

Uh oh!

DougGregor Apr 10, 2017

Uh oh!

DougGregor Apr 10, 2017

Uh oh!

slavapestov Apr 10, 2017

Uh oh!

DougGregor Apr 10, 2017

Uh oh!

slavapestov Apr 10, 2017

Uh oh!

slavapestov Apr 10, 2017

Uh oh!

DougGregor Apr 10, 2017

Uh oh!

jrose-apple Apr 10, 2017

Uh oh!

DougGregor Apr 10, 2017

Uh oh!

slavapestov commented Apr 11, 2017

Uh oh!

Uh oh!

Preliminary Sema and AST support for subclass existentials (SE-0156) #8650

Preliminary Sema and AST support for subclass existentials (SE-0156) #8650

Uh oh!

Conversation

slavapestov commented Apr 9, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

slavapestov commented Apr 11, 2017

Uh oh!

Uh oh!

slavapestov commented Apr 9, 2017 •

edited

Loading