Open lcnr opened 1 month ago
The job mingw-check-tidy
failed! Check out the build log: (web) (plain)
@bors try
@bors try
:hourglass: Trying commit a0359c8fddeca7ffe8c75277e1da71cb94ab83a6 with merge 2466b92ed5feb282a98bb984f45d1e6d39f8c1aa...
:sunny: Try build successful - checks-actions
Build commit: 2466b92ed5feb282a98bb984f45d1e6d39f8c1aa (2466b92ed5feb282a98bb984f45d1e6d39f8c1aa
)
@craterbot check
:ok_hand: Experiment pr-124592
created and queued.
:robot: Automatically detected try build 2466b92ed5feb282a98bb984f45d1e6d39f8c1aa
:mag: You can check out the queue and this experiment's details.
:information_source: Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more
:construction: Experiment pr-124592
is now running
:information_source: Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more
:tada: Experiment pr-124592
is completed!
:bar_chart: 51 regressed and 4 fixed (444840 total)
:newspaper: Open the full report.
:warning: If you notice any spurious failure please add them to the blacklist! :information_source: Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more
:bar_chart: 51 regressed and 4 fixed (444840 total)
Minimizations:
tc-collection
u64
/ T
mismatchAndlon/ice_testcase
tests/ui/associated-item/issue-105449.rs
droundy/sad-monte-carlo
imgui
@lcnr, I just went through the crater reports of all 47 “unknown” regressions. Some of them were spurious (no space left on device), all of the the remaining ones are type mismatches of the expected kind as well as secondary regressions only (except for redst4r/bustools_cli-rs / bustools_cli-0.2.1) with the primary regression being imgui
in most cases and tc-collection
otherwise (downstream crates are owned by the same person (monorepo) in the latter case).
As discussed, this is ready for an FCP. I will open “incoming breakage” PRs for the relevant crates if/once this PR gets accepted.
This PR changes the rule to candidate winnowing during selection. We prefer candidates over others, both to guide inference and to avoid ambiguity in case there are multipe applicable candidates.
The current preference rules aren't a proper order, making candidate selection order-dependent. The issue arrises for "global ParamEnv
candidates": where-bounds which are not higher-ranked and do not mention any generic parameters.
This current preference rules are as follows
non-global ParamEnv > impl
impl > global ParamEnv
global ParamEnv == non-global ParamEnv
I propose to change these rules to a proper ordering:
non-global ParamEnv > impl > global ParamEnv
This avoids order-dependence and is easier to support in the next-generation trait solver. The current behavior is also unintuitive.
This change adds additional incomplete inference guidance in cases with
ParamEnv
candidateParamEnv
candidateWith this setup, we previously did not use the impls to drop the global ParamEnv
candidate as the impls were first dropped via the non-global candidate.
If there were more than 2 or 3 impl candidates, we ended dropping the global ParamEnv
candidates via an impl candidate before all impls were dropped due to the non-global ParamEnv
candidate. This subtle behavior is caused by using swap_remove
when dropping impl candidates: https://github.com/rust-lang/rust/blob/cf2baaa8350c9cac9a5bc139926bcb246303b9f8/compiler/rustc_trait_selection/src/traits/select/mod.rs#L498-L508
This causes the following patterns to change behavior
while keeping the behavior of the patterns in
The new solver currently does not implement the lowered priority of global ParamEnv
candidates, so the divergence between it and the old solver in the added tests will be resolved in favor of the old solver behavior after this PR.
There are multiple existing crates which break due to inference changes, see https://github.com/rust-lang/rust/pull/124592#issuecomment-2104541495. All breakage should be fixable by adding explicit type annotations and we intend to open PRs doing so once this is in FCP. Thank you @fmease for minimizing them.
@rfcbot fcp merge
Team member @lcnr has proposed to merge this. The next step is review by the rest of the tagged team members:
No concerns currently listed.
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
See this document for info about what commands tagged team members can give me.
is imgui not a relatively significant crate to be breaking? I would expect that to be being used by a lot of projects :thinking:
I still think we should go ahead with it. The fix to it will be local. I don't mind if we have to keep this regression on nightly for 1 or 2 versions
and make sure it's actually a partial ordering :< the previous ordering was:
The new solver currently does not implement the lowered priority of global
ParamEnv
candidates, so the divergence between it and the old solver in the added tests will be resolved in favor of the old solver behavior after this PR.r? @compiler-errors