-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Remove PredicateKind::ClosureKind
#118120
Conversation
r? @cjgillot (rustbot has picked a reviewer for you, use r? to override) |
Some changes occurred to the core trait solver cc @rust-lang/initiative-trait-system-refactor |
r? types cc @rust-lang/types |
compiler/rustc_trait_selection/src/traits/error_reporting/type_err_ctxt_ext.rs
Outdated
Show resolved
Hide resolved
candidates.vec.push(ClosureCandidate { is_const }); | ||
} else { | ||
candidates.ambiguous = true; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this slightly weakens inference, does it? we now stall closure: FnMut
if we don't yet know the closure kind while we could now use that goal to infer e.g. the signature of the closure?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, since we always make progress on a corresponding FnOnce projection that gets emitted besides it, which will always make sure we constrain the signature.
I don't immediately see a case where stalling an FnMut or Fn trait goal itself will cause inference to be affected negatively, as long as we can make progress on the projection goal and make inference progress on the closure's signature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, that's because the only stable usage of the Fn
traits is via paren sugar which always results in a projection predicate as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, specifically an FnOnce
projection goal, which we don't even check the closure kind in (old solver) projection.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could result in inference changes if you use the unboxed_closure syntax + raw fn_traits + custom FnMut
impl with where clauses that affect inference, but that's 1. unstable, and 2. not something we can support in the new trait solver, so I don't feel particularly symathetic to that use-case even if it does exist (which I'm almost certain it does not).
@bors try @rust-timer queue would like to run crater here in case my understanding is correct. |
This comment has been minimized.
This comment has been minimized.
Remove `PredicateKind::ClosureKind` We don't need the `ClosureKind` predicate kind -- instead, `Fn`-family trait goals are left as ambiguous, and we only need to make progress on `FnOnce` projection goals for inference purposes. This is similar to how we do confirmation of `Fn`-family trait and projection goals in the new trait solver, which also doesn't use the `ClosureKind` predicate. Some hacky logic is added in the second commit so that we can keep the error messages the same.
☔ The latest upstream changes (presumably #117580) made this pull request unmergeable. Please resolve the merge conflicts. |
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
alright r=me after rebase and nits then |
I guess it doesn't hurt to run crater too @craterbot check |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
3c03780
to
128feaa
Compare
This PR changes Stable MIR cc @oli-obk, @celinval, @spastorino, @ouz-a |
Finished benchmarking commit (a832c07): comparison URL. Overall result: ✅ improvements - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 674.399s -> 675.879s (0.22%) |
We can always revert or fix-forward if regressions are detected in crater, so I will land this now. @bors r=lcnr |
☀️ Test successful - checks-actions |
Finished benchmarking commit (1e9dda7): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 675.709s -> 675.896s (0.03%) |
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🎉 Experiment
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🎉 Experiment
|
We don't need the
ClosureKind
predicate kind -- instead,Fn
-family trait goals are left as ambiguous, and we only need to make progress onFnOnce
projection goals for inference purposes.This is similar to how we do confirmation of
Fn
-family trait and projection goals in the new trait solver, which also doesn't use theClosureKind
predicate.Some hacky logic is added in the second commit so that we can keep the error messages the same.