Skip to content

[ASTPrinter] Print the desugared constraint type following the any keyword. #59041

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
May 24, 2022

Conversation

hborla
Copy link
Member

@hborla hborla commented May 24, 2022

Currently, a protocol typealias with an underlying constraint type (i.e. a protocol or protocol composition) can be used as an existential type by accessing the alias through a type parameter, e.g.

protocol P1 {
  typealias A = P2
}

protocol P2 {}

func generic<T: P1>(value: (T) -> T.A) {} // okay

However, verifying that the underlying type of T.A is a constraint type is a circular computation in the general case, which is needed to use the any keyword. Resolving T.A where T is a type parameter needs a full generic signature to access the requirements on T, but a full generic signature needs the existential type verification.

This is an issue when T.A is written in source, but any is automatically printed in Swift interfaces. For now, simply print the underlying constraint type.

Resolves: rdar://93780361

@hborla hborla requested review from slavapestov and tshortli May 24, 2022 02:53
@hborla
Copy link
Member Author

hborla commented May 24, 2022

@swift-ci please smoke test

PrintOptions flag that is only enabled for interface printing.
@hborla
Copy link
Member Author

hborla commented May 24, 2022

@swift-ci please smoke test

}

// CHECK: public func dependentExistential<T>(value: (T) -> any main.P) where T : main.ProtocolTypealias
public func dependentExistential<T: ProtocolTypealias>(value: (T) -> T.A) {}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My only hesitation here is that we might want to think about whether this interferes with the ability of -preserve-types-as-written to help library owners work around naming ambiguities. There are already places where library owners can't control the type names that are written into the interface, though, so maybe it's not much of a regression to lack control for this kind of signature.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think -preserve-types-as-written will skip this code path entirely, right? It should print the TypeRepr if available (which will print T.A without any) and not look at the Type at all.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In any case, this isn't a long term fix; either we need to figure out how to make any with protocol typealiases work (seems unlikely), or eventually ban them in source.

@hborla hborla merged commit 7cb0c28 into swiftlang:main May 24, 2022
@hborla hborla deleted the protocol-typealias-existential branch May 24, 2022 19:52
@AnthonyLatsis
Copy link
Collaborator

By a cycle, do you mean something like this?

protocol P1 {
  associatedtype Assoc

  typealias A = P2
}
protocol P2 {}

func foo<T: P1>(t: T) where T.Assoc == any T.A {}

Sorry to bother, just trying to puzzle out some criteria for these cycles. AFAICT, they can really happen only if any T.A appears in a generic requirement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants