Skip to content

[Typed throws] Support overrides that are contravariant in the thrown error #69839

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 12 commits into from
Nov 16, 2023

Conversation

DougGregor
Copy link
Member

No description provided.

Adopt typed throws for the `map` operation to propagate thrown error
types through the `map` API. This is done in a manner that is backward
compatible for almost all cases:

* The new typed-throws entrypoint is `@_alwaysEmitIntoClient` so it
can back-deploy all the way back.
* The old `rethrows` entrypoint is left in place, using
`@usableFromInline` with `internal` so it is part of the ABI but not
the public interface, and `@_disfavoredOverload` so the type checker
avoids it while building the standard library itself. The old
entrypoint is implemented in terms of the new one.

Note that the implementation details for the existential collection
"box" classes rely on method overriding of `_map` operations, and the
types are frozen, so  we don't get to change their signatures. However,
these are only implementations, not API: the actual API `map`
functions can be upgraded to typed throws.

Note that this code makes use of a known hole in `rethrows` checking
to allow calling between `rethrows` and typed throws. We'll need to do
something about this for source-compatibility reasons, but I'll follow
up with that separately.
Replace the hackish use of `@_disfavoredOverload` with the more principled
use of `@_silgen_name` for the entrypoint we are maintaining, then rename
these functions in source to `__rethrows_map` to indicate what they're for.

While here, make them `throws` instead of `rethrows`. The ABI is the
same, and `throws` allows us do avoid to do/catch tricks with rethrows
functions.
…rows

These class methods are internal, but because they are overridden and are
part of a `@usableFromInline`, `@_fixed_layout` class, we they can't be
moved over to typed throws without breaking ABI. However, they are
only ever called from typed-throws functions, which already need a
do...catch dance to downcast the error itself. Make them `throws`
instead, which is ABI-compatible, but eliminates the need for
do...catch hackery in the function itself.
When substitution into a function type with `throws(E)` produces either
`throws(any Error)` or `throws(Never)`, adjust the resulting function
type to the equivalent `throws` or non-throwing.
SIL opaque values do not yet support typed throws, so avoid the API that
uses them.
@DougGregor
Copy link
Member Author

@swift-ci please smoke test

@DougGregor DougGregor enabled auto-merge November 14, 2023 06:32
@DougGregor DougGregor mentioned this pull request Nov 14, 2023
21 tasks
@DougGregor DougGregor force-pushed the typed-throws-override branch from 467e6d2 to 225360b Compare November 15, 2023 21:12
@DougGregor
Copy link
Member Author

@swift-ci please smoke test

@DougGregor
Copy link
Member Author

@swift-ci please smoke test

1 similar comment
@DougGregor
Copy link
Member Author

@swift-ci please smoke test

@DougGregor
Copy link
Member Author

@swift-ci please smoke test Linux

@DougGregor DougGregor merged commit 975519b into swiftlang:main Nov 16, 2023
@DougGregor DougGregor deleted the typed-throws-override branch November 16, 2023 18:35
@DougGregor DougGregor restored the typed-throws-override branch November 16, 2023 18:35
@DougGregor DougGregor deleted the typed-throws-override branch November 16, 2023 18:35
@DougGregor DougGregor restored the typed-throws-override branch November 16, 2023 18:35
@DougGregor DougGregor deleted the typed-throws-override branch November 16, 2023 18:35
@DougGregor
Copy link
Member Author

Whoops. I landed way more than I wanted to here, so I've reverted this PR and opened another with the intended functionality

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.

1 participant