Skip to content

Sema: Remove ConstraintKind::OneWayBindParam and ConstraintKind::OneWayEqual #78301

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 9 commits into from
Jan 5, 2025

Conversation

slavapestov
Copy link
Contributor

No description provided.

@xedin
Copy link
Contributor

xedin commented Dec 19, 2024

@swift-ci please test source compatibility

@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

@xedin
Copy link
Contributor

xedin commented Dec 19, 2024

For posterity.

This might cause a difference in behavior for things like:

for (q, a) in [("ultimate question", 42)] where a == 42 {
}

because a is going to be inferred together with == as part of the where clause. This is not the case for closure contexts where where clause is always separate from the pattern.

@xedin
Copy link
Contributor

xedin commented Dec 19, 2024

I think we can follow-up with a small refactoring of TypeChecker::typeCheckForEachPreamble to do what CSSyntacticElement does with where clause.

@slavapestov slavapestov force-pushed the remove-one-way-constraints branch from 8cc6da2 to 2d48060 Compare December 19, 2024 20:36
Copy link
Collaborator

@AnthonyLatsis AnthonyLatsis left a comment

Choose a reason for hiding this comment

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

(Last 2 commits) Neat!

slavapestov and others added 9 commits December 21, 2024 00:42
…tely

Instead of using `one-way` constraints, just like in closure contexts
for-in statements should type-check their `where` clauses separately.

This also unifies and simplifies for-in preamble handling in the
solver.
…al base in diagnostic mode

Re-introduce unsolved member constraint when optional object is
a type variable or member until it's bound, otherwise it's impossible
to tell whether unwrapped base would have a member or not.
…ied to a member

`TVO_PrefersSubtypeBinding` in this case is intended to support
references to Objective-C imported members that can be force
unwrapped before being used i.e. accessing an overloaded method
on `AnyObject` should always prefer an overload that returns
a subtype:

```
@objc class A: NSObject {
    @objc func test() -> A { }
    @objc func test() -> B { }
}

func test(obj: AnyObject) {
  obj.test!()
}
```

where `B` is a subtype of `A` should result in selection of
`() -> B`.
@xedin xedin force-pushed the remove-one-way-constraints branch from a0fbd89 to 80a988e Compare December 21, 2024 08:42
@xedin
Copy link
Contributor

xedin commented Dec 21, 2024

@swift-ci please test

@xedin
Copy link
Contributor

xedin commented Dec 21, 2024

@swift-ci please test source compatibility

@xedin
Copy link
Contributor

xedin commented Dec 21, 2024

@swift-ci please test source compatibility debug

@xedin
Copy link
Contributor

xedin commented Dec 22, 2024

Debug config failures are unrelated to these changes, main fails the same way - https://ci.swift.org/job/swift-main-source-compat-suite-debug/989/

@slavapestov
Copy link
Contributor Author

@swift-ci Please test

@slavapestov
Copy link
Contributor Author

@swift-ci Please test source compatibility

@slavapestov slavapestov merged commit 2d17294 into swiftlang:main Jan 5, 2025
5 of 7 checks passed
slavapestov added a commit that referenced this pull request Feb 2, 2025
slavapestov added a commit to slavapestov/swift that referenced this pull request Feb 25, 2025
I had to revert swiftlang#78301 to fix
rdar://143338891.

This now brings back the change, but without deleting code; instead,
it's guarded by the -disable-optimized-restrictions flag. Once the
flag is removed, I will once again completely delete OneWayEqual
constraints.
slavapestov added a commit to slavapestov/swift that referenced this pull request Feb 25, 2025
I had to revert swiftlang#78301 to fix
rdar://143338891.

This now brings back the change, but without deleting code; instead,
it's guarded by the -disable-optimized-restrictions flag. Once the
flag is removed, I will once again completely delete OneWayEqual
constraints.
slavapestov added a commit to slavapestov/swift that referenced this pull request Feb 27, 2025
I had to revert swiftlang#78301 to fix
rdar://143338891.

This now brings back the change, but without deleting code; instead,
it's guarded by the -disable-optimized-restrictions flag. Once the
flag is removed, I will once again completely delete OneWayEqual
constraints.
slavapestov added a commit to slavapestov/swift that referenced this pull request Feb 28, 2025
I had to revert swiftlang#78301 to fix
rdar://143338891.

This now brings back the change, but without deleting code; instead,
it's guarded by the -disable-optimized-restrictions flag. Once the
flag is removed, I will once again completely delete OneWayEqual
constraints.
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.

3 participants