Skip to content

[Constraint solver] Track "isolated by preconcurrency" in the solver. #59963

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

Conversation

DougGregor
Copy link
Member

Rather than only setting the isolated-by-preconcurrency bit during
constraint application, track the closures it will be set for as part
of the constraint system and solution. Then, use that bit when
performing "strict concurrency context" checks and type adjustments,
so we don't treat an inferred-to-by-@Sendable-by-preconcurrency
closure in the solver as if it weren't related to preconcurrency.

Fixes the spurious warning from #59910.

Rather than re-using `DiagnosticBehavior` to describe how a fix should
act, introduce `FixBehavior` to cover the differences between (e.g.)
always-as-awarning and downgrade-to-warning. While here, split the
`isWarning` predicate into two different predicates:

* `canApplySolution`: Whether we can still apply a solution when it
contains this particular fix.
* `affectsSolutionScore`: Whether

These two predicates are currently tied together, because that's the
existing behavior, but we don't necessarily want them to stay that way.
This allows us to still maintain them in the score kind, but not treat
them as being as severe as an error requiring a fix.
This avoids us having to go down the less-efficient "salvage" path when
dealing with concurrency issues. It also fixes overloading behavior
when dealing with `@preconcurrency` and `@Sendable` functions,
such as in swiftlang#59909.
Rather than only setting the isolated-by-preconcurrency bit during
constraint application, track the closures it will be set for as part
of the constraint system and solution. Then, use that bit when
performing "strict concurrency context" checks and type adjustments,
so we don't treat an inferred-to-by-`@Sendable`-by-preconcurrency
closure in the solver as if it weren't related to preconcurrency.

Fixes the spurious warning from
swiftlang#59910.
@DougGregor
Copy link
Member Author

@swift-ci please smoke test

@DougGregor
Copy link
Member Author

Note: only the last commit is new, building on top of #59958

@DougGregor DougGregor merged commit b9afb79 into swiftlang:main Jul 8, 2022
@DougGregor DougGregor deleted the constraint-system-preconcurrency branch July 8, 2022 16:52
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