Skip to content

[CSBindings] Prevent BindingSet::isViable from dropping viable bindings #76487

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 1 commit into from
Sep 17, 2024

Conversation

xedin
Copy link
Contributor

@xedin xedin commented Sep 16, 2024

I think the original idea was to elide Array<$T> if there is a
binding a resolved generic arguments i.e. Array<Float>, but
the check doesn't account for the fact that bindings could be
of different kinds and there are some implicit conversions that
could be missed if we remove the bindings.

For example, given the following constraints:

Array<$T0> conv $T1
$T1 conv Array<(String, Int)>

$T0 can be a supertype of Array<$T0> and subtype of Array<(String, Int)>.

The solver should accept both types as viable bindings because the $T0
could be bound to (key: String, value: Int) and that would match Array<(String, Int)> conversion.

…ings

I think the original idea was to elide `Array<$T>` if there is
a binding a resolved generic arguments i.e. `Array<Float>`, but
the check doesn't account for the fact that bindings could be
of different kinds and there are some implicit conversions that
could be missed if we remove the bindings.

For example, given the following constraints:

`Array<$T0> conv $T1`
`$T1 conv Array<(String, Int)>`

`$T0` can be a supertype of `Array<$T0>` and subtype of `Array<(String, Int)>`.

The solver should accept both types as viable bindings because the
`$T0` could be bound to `(key: String, value: Int)` and that would
match `Array<(String, Int)>` conversion.
@xedin
Copy link
Contributor Author

xedin commented Sep 16, 2024

@swift-ci please test

@xedin
Copy link
Contributor Author

xedin commented Sep 16, 2024

@swift-ci please test source compatibility

@xedin xedin merged commit afcf38e into swiftlang:main Sep 17, 2024
7 checks passed
xedin added a commit to xedin/swift that referenced this pull request Oct 21, 2024
…collection types

This is follow-up to swiftlang#76487

It's reasonable to coalesce bindings of different kind if they don't
allow implicit conversions like stdlib collection types do.

Resolves: swiftlang#77003
xedin added a commit to xedin/swift that referenced this pull request Oct 21, 2024
…collection types

This is follow-up to swiftlang#76487

It's reasonable to coalesce bindings of different kind if they don't
allow implicit conversions like stdlib collection types do.

Resolves: swiftlang#77003
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