[SE-0335] Enable explicit existential types. #40666

hborla · 2021-12-21T21:29:53Z

This change enables explicit existential types by default, which changes the representation of existential types to use ExistentialType, and allows the any keyword in the source language.

Note that many of the conditional getAs<ExistentialType>() variable bindings are temporary. After explicit existential types are enabled, existential types will always resolve to ExistentialType (regardless of whether or not they're spelled with any), and the isExistentialType() checks can be changed to is<ExistentialType>(). I'm holding off on making that change for now to allow explicit existential types to be turned off if needed.

Resolves: rdar://86347236

lib/AST/GenericSignature.cpp

hborla · 2022-01-08T08:16:03Z

@swift-ci please test

hborla · 2022-01-08T08:16:13Z

@swift-ci please test source compatibility

swift-ci · 2022-01-08T09:38:58Z

Build failed
Swift Test Linux Platform
Git Sha - 1c1ea7703266075446bb34b15bc0ddcbb9cf933c

swift-ci · 2022-01-08T11:09:46Z

Build failed
Swift Test OS X Platform
Git Sha - 1c1ea7703266075446bb34b15bc0ddcbb9cf933c

hborla · 2022-01-09T00:33:06Z

@swift-ci please test

hborla · 2022-01-09T00:33:15Z

@swift-ci please test source compatibility

swift-ci · 2022-01-09T02:30:09Z

Build failed
Swift Test Linux Platform
Git Sha - 8d2e059c90debc9252b229d5dc55b4e23a4a3fb6

swift-ci · 2022-01-09T04:13:32Z

Build failed
Swift Test OS X Platform
Git Sha - 8d2e059c90debc9252b229d5dc55b4e23a4a3fb6

hborla · 2022-01-10T18:59:41Z

include/swift/AST/Types.h

@@ -2731,6 +2734,8 @@ class ExistentialMetatypeType : public AnyMetatypeType {
  static bool classof(const TypeBase *T) {
    return T->getKind() == TypeKind::ExistentialMetatype;
  }
+
+  Type getExistentialInstanceType();


I don't like the existence of this method, but it messes up TypeWalker if I make AnyMetatypeType::getInstanceType() return ExistentialType for existential metatypes. Alternatively, I could add getRawInstanceType() or something like that for the few places that actually need the stored InstanceType. Really, I'd like to just replace ExistentialMetatypeType with ExistentialType(MetatypeType(...))

I think your longer-term goal of removing ExistentialMetatypeType is good and in the meantime, this workaround is reasonable.

hborla · 2022-01-11T07:52:45Z

@swift-ci please test

hborla · 2022-01-11T07:52:52Z

@swift-ci please test source compatibility

swift-ci · 2022-01-11T09:30:04Z

Build failed
Swift Test Linux Platform
Git Sha - 7d9661eb79ff558bb40f94ac01605329487d6110

swift-ci · 2022-01-11T11:40:07Z

Build failed
Swift Test OS X Platform
Git Sha - 7d9661eb79ff558bb40f94ac01605329487d6110

hborla · 2022-01-11T17:29:15Z

@swift-ci please test source compatibility

hborla · 2022-01-12T00:12:57Z

swiftlang/llvm-project#3777

@swift-ci please test

swift-ci · 2022-01-12T03:02:49Z

Build failed
Swift Test OS X Platform
Git Sha - a7b50a06a4ceec3756d399c681f5e8affc9e3bc5

swift-ci · 2022-01-12T03:11:34Z

Build failed
Swift Test Linux Platform
Git Sha - a7b50a06a4ceec3756d399c681f5e8affc9e3bc5

hborla · 2022-01-12T03:56:11Z

swiftlang/llvm-project#3777

@swift-ci please test

in ExistentialType for the type of error values.

existential types.

…able initializer requirements with explicit existential Encodable and Decodable parameters.

the ClangImporter.

finding the protocol decl for an existential type.

explicit ExistentialType. The ASTDemangler needs to produce ExistentialType based on context, not unconditionally when producing a protocol composition. This is tricky because existential types are mangled the same way as other protocol references, e.g. in conformance requirements. For now, drop the explicit existentials when reconstructing types.

must be marked with 'any' as a warning.

resolve to ProtocolType or ProtocolCompositionType are always existential types. This can happen because type aliases to protocol constraints can also be used as type witnesses. The type alias itself is still a constraint, because it can be used in generic signatures in addition to being used as an existential type, e.g. in parameter position. So, we need to wrap the type alias in an ExistentialType during type witness resolution.

metatypes always wrap the constraint type directly, and the instance type of an existential metatype is an existential type.

…icit existential types.

existential types. Use the correct type resolver context when resolving SIL metatypes and function types, and diagnose an error if an explicit existential type appears in a protocol composition.

various places that expect ProtocolType or ProtocoolCompositionType.

are printed with the `any` keyword. For now, printing `any` is off by default in order to turn on explicit existential types with minimal changes to the test suite. The option will also allow control over how existential types are printed in Swift interfaces.

explicit existential types are enabled.

…Type by propagating whether the decoded type is for a requirement through TypeDecoder.

existential arguments to not return before checking the second argument type.

…ence when the member is a typealias to a protocol or composition.

hborla · 2022-01-14T06:46:03Z

@swift-ci please test source compatibility

hborla · 2022-01-14T06:46:10Z

@swift-ci please smoke test

hborla · 2022-01-14T20:10:14Z

@swift-ci please smoke test macOS platform

ahoppen · 2022-01-17T17:30:57Z

This PR caused is causing a few crashes in the stress tester: SR-15742.

AnthonyLatsis · 2022-01-26T11:31:43Z

lib/ClangImporter/ImportType.cpp

@@ -1183,6 +1183,10 @@ namespace {
            }
          }

+          if (bridgedType->isConstraintType() &&


Can bridgedType really happen to be an protocol/composition here, or was this a forethought?

Yes, it can be Error

AnthonyLatsis · 2022-01-26T18:57:11Z

lib/AST/TypeJoinMeet.cpp

+  auto joinInstance = join(firstConstraint, secondConstraint);
+  if (!joinInstance)
+    return CanType();
+
+  if (joinInstance->is<ExistentialMetatypeType>() ||
+      joinInstance->isAny() ||
+      joinInstance->isAnyObject())


Note: is<ExistentialMetatypeType>() seems unnecessary here.

I believe I removed this code in my follow-up PR but I'm not certain

EDIT: oops, this is my follow up PR, I got it confused with the original 😅

Ah, I did remove this bit of code in a follow-up commit in this PR. You're right that it's unnecessary.

Whoops, sorry, I ought to have checked if it's still there on main.

slavapestov reviewed Dec 22, 2021

View reviewed changes

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

hborla force-pushed the explicit-existential-fixes branch from c1a9a0f to 54783da Compare December 22, 2021 03:10

hborla force-pushed the explicit-existential-fixes branch 2 times, most recently from 2e4e40b to 1c1ea77 Compare January 8, 2022 07:22

hborla changed the title ~~[Type System] Various bug fixes for explicit existential types.~~ [SE-0335] Enable explicit existential types. Jan 8, 2022

hborla force-pushed the explicit-existential-fixes branch 2 times, most recently from dfb922f to 8d2e059 Compare January 8, 2022 23:56

hborla commented Jan 10, 2022

View reviewed changes

hborla marked this pull request as ready for review January 10, 2022 20:20

hborla force-pushed the explicit-existential-fixes branch from 7d9661e to a7b50a0 Compare January 11, 2022 17:28

This was referenced Jan 11, 2022

[5.6][SE-0335] Enable explicit existential types. #40804

Merged

[lldb] Teach LLDB about ExistentialType in the Swift AST. swiftlang/llvm-project#3777

Closed

slavapestov approved these changes Jan 12, 2022

View reviewed changes

hborla added 19 commits January 13, 2022 19:30

[Type System] When explicit existential types are enabled, wrap Error

6cee193

in ExistentialType for the type of error values.

[GenericSignature] Don't allow conformance requirements with explicit

a7fa469

existential types.

[Codable] When explicit existential types are enabled, synthesize Cod…

f6f53f6

…able initializer requirements with explicit existential Encodable and Decodable parameters.

[Interop] Handle existential types in ClangTypeConverter and

86730ca

the ClangImporter.

[SILOptimizer] Use the constraint type in ExistentialSpecializer when

1d56338

finding the protocol decl for an existential type.

[Diagnostics] Stage in the new error message for existential types that

5e4fbc4

must be marked with 'any' as a warning.

[Type System] With explicit existential types, make sure existential

d971d48

metatypes always wrap the constraint type directly, and the instance type of an existential metatype is an existential type.

[Sema] Implement type join for existential types.

b7c6348

[ConstraintSystem] Fix a few constraint system corner cases with expl…

5dced8e

…icit existential types.

[TypeResolver] Fix a few corner cases in type resolution for explicit

f018328

existential types. Use the correct type resolver context when resolving SIL metatypes and function types, and diagnose an error if an explicit existential type appears in a protocol composition.

[Type System] Use the constraint type of an existential type in

6e6ca13

various places that expect ProtocolType or ProtocoolCompositionType.

[Type System] Enable explicit existential types.

ee331a8

[AST] Teach ExistentialType::get to only produce ExistentialType when

6060de6

explicit existential types are enabled.

[Diagnostics] Remove the warning for 'any Any' and 'any AnyObject'.

c48b593

[Type Reconstruction] Re-construct existential types with Existential…

992a871

…Type by propagating whether the decoded type is for a requirement through TypeDecoder.

[Sema] Fix the source compatibility check for member operators with

6608bf8

existential arguments to not return before checking the second argument type.

hborla force-pushed the explicit-existential-fixes branch from a7b50a0 to 6608bf8 Compare January 14, 2022 03:31

[ConstraintSystem] Return an existential type in getTypeOfMemberRefer…

626bea2

…ence when the member is a typealias to a protocol or composition.

hborla merged commit d146b69 into swiftlang:main Jan 15, 2022

hborla deleted the explicit-existential-fixes branch January 15, 2022 00:38

AnthonyLatsis reviewed Jan 26, 2022

View reviewed changes

ahoppen mentioned this pull request Dec 12, 2022

[SR-15742] Unreachable "these types are always canonical" executed #58019

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[SE-0335] Enable explicit existential types. #40666

[SE-0335] Enable explicit existential types. #40666

hborla commented Dec 21, 2021 •

edited

Loading

hborla commented Jan 8, 2022

hborla commented Jan 8, 2022

swift-ci commented Jan 8, 2022

swift-ci commented Jan 8, 2022

hborla commented Jan 9, 2022

hborla commented Jan 9, 2022

swift-ci commented Jan 9, 2022

swift-ci commented Jan 9, 2022

hborla Jan 10, 2022

slavapestov Jan 11, 2022

hborla commented Jan 11, 2022

hborla commented Jan 11, 2022

swift-ci commented Jan 11, 2022

swift-ci commented Jan 11, 2022

hborla commented Jan 11, 2022

hborla commented Jan 12, 2022

swift-ci commented Jan 12, 2022

swift-ci commented Jan 12, 2022

hborla commented Jan 12, 2022

hborla commented Jan 14, 2022

hborla commented Jan 14, 2022

hborla commented Jan 14, 2022

ahoppen commented Jan 17, 2022

AnthonyLatsis Jan 26, 2022

hborla Jan 26, 2022

AnthonyLatsis Jan 26, 2022

hborla Jan 26, 2022 •

edited

Loading

hborla Jan 26, 2022

AnthonyLatsis Jan 26, 2022

[SE-0335] Enable explicit existential types. #40666

[SE-0335] Enable explicit existential types. #40666

Conversation

hborla commented Dec 21, 2021 • edited Loading

hborla commented Jan 8, 2022

hborla commented Jan 8, 2022

swift-ci commented Jan 8, 2022

swift-ci commented Jan 8, 2022

hborla commented Jan 9, 2022

hborla commented Jan 9, 2022

swift-ci commented Jan 9, 2022

swift-ci commented Jan 9, 2022

hborla Jan 10, 2022

Choose a reason for hiding this comment

slavapestov Jan 11, 2022

Choose a reason for hiding this comment

hborla commented Jan 11, 2022

hborla commented Jan 11, 2022

swift-ci commented Jan 11, 2022

swift-ci commented Jan 11, 2022

hborla commented Jan 11, 2022

hborla commented Jan 12, 2022

swift-ci commented Jan 12, 2022

swift-ci commented Jan 12, 2022

hborla commented Jan 12, 2022

hborla commented Jan 14, 2022

hborla commented Jan 14, 2022

hborla commented Jan 14, 2022

ahoppen commented Jan 17, 2022

AnthonyLatsis Jan 26, 2022

Choose a reason for hiding this comment

hborla Jan 26, 2022

Choose a reason for hiding this comment

AnthonyLatsis Jan 26, 2022

Choose a reason for hiding this comment

hborla Jan 26, 2022 • edited Loading

Choose a reason for hiding this comment

hborla Jan 26, 2022

Choose a reason for hiding this comment

AnthonyLatsis Jan 26, 2022

Choose a reason for hiding this comment

hborla commented Dec 21, 2021 •

edited

Loading

hborla Jan 26, 2022 •

edited

Loading