Skip to content

[TypeChecker/SILGen] Allow any Sendable to match Any while matching generic arguments #78171

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 13 commits into from
Dec 18, 2024

Conversation

xedin
Copy link
Contributor

@xedin xedin commented Dec 13, 2024

Allow any Sendable to match Any constraint while matching
generic arguments i.e. [any Sendable] -> [Any] when any Sendable
type comes from context that involves @preconcurrency declarations.

To facilitate that we need a new expression that models an unsafe bitcast
from one type to the other - UnsafeCastExpr. This expression is going
to be introduced by the solver during solution application phase to
erase any Sendable to Any in generic argument positions.

Resolves: rdar://140300022

xedin added 11 commits December 10, 2024 17:39
…ndable`

Prevent generic arguments from being assigned `any Sendable`
directly, that should only happen through inference. This is
required because we allow `any Sendable` -> `Any` conversion
in modes without strict concurrency enabled to maintain source
compatibility and let the developers annotate existing APIs
with `any Sendable` and other concurrency attributes.
…ic arguments

Allow `any Sendable` to match `Any` constraint while matching
generic arguments i.e. `[any Sendable]` -> `[Any]` when `any Sendable`
type comes from context that involves `@preconcurrency` declarations
in non-strict concurrency compiler mode.

Note that it's currently impossible to figure out precisely
where `any Sendable` type came from.
`UnsafeCastExpr` - A special kind of conversion that performs an unsafe
bitcast from one type to the other.

Note that this is an unsafe operation and type-checker is allowed to
use this only in a limited number of cases like: `any Sendable` -> `Any`
conversions in some positions, covariant conversions of function and
function result types.
…c arguments

In non-strict concurrency mode when `@preconcurrency` declarations
are involved `any Sendable` should be treated as `Any` in generic
argument positions to support passing types that (partially) adopted
concurrency annotations to types that haven't yet done so.
Forwarding cast handles ownership correctly and doesn't disable
optimizations unlike bitcast.
…ainst marker protocol

This indicates that the type doesn't have appropriate annotations
i.e. for concurrency or ownership.
…of generic arguments

Conversion restrictions like "deep equality" could produce a more
narrow/actionable fixes.
…e same

This helps to avoid spurious failures pointing to involved pattern types
because they won't match exactly if shape types are not the same.
@xedin
Copy link
Contributor Author

xedin commented Dec 13, 2024

We can use UnsafeCastExpr to model both CovariantFunctionConversionExpr and CovariantReturnConversionExpr. I'll attempt to make that chance one this lands.

@xedin
Copy link
Contributor Author

xedin commented Dec 13, 2024

@swift-ci please test

Copy link
Contributor

@atrick atrick left a comment

Choose a reason for hiding this comment

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

SILGenBuilder::createUncheckedForwardingCast LGTM

@xedin
Copy link
Contributor Author

xedin commented Dec 13, 2024

@swift-ci please test

@xedin xedin force-pushed the rdar-140300022 branch 2 times, most recently from cbcb24f to 20a5a51 Compare December 13, 2024 20:10
@xedin
Copy link
Contributor Author

xedin commented Dec 13, 2024

@swift-ci please test

…ction argument/result positions in generic argument context
@xedin
Copy link
Contributor Author

xedin commented Dec 14, 2024

@swift-ci please test

@xedin
Copy link
Contributor Author

xedin commented Dec 14, 2024

@swift-ci please test source compatibility debug

@xedin
Copy link
Contributor Author

xedin commented Dec 15, 2024

@swift-ci please test macOS platform

@xedin
Copy link
Contributor Author

xedin commented Dec 16, 2024

@swift-ci please test

@xedin
Copy link
Contributor Author

xedin commented Dec 16, 2024

@swift-ci please test source compatibility

@xedin
Copy link
Contributor Author

xedin commented Dec 18, 2024

@swift-ci please smoke test macOS platform

@xedin xedin merged commit 636525e into swiftlang:main Dec 18, 2024
7 checks passed
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.

2 participants