cleanup candidate_should_be_dropped_in_favor_of

[lcnr]

and make sure it's actually a partial ordering :< the previous ordering was:

• non-global where-bounds are preferred over impls
• impls are preferred over global where-bound
• non-global where-bounds and global where-bounds are considered equal

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

[lcnr]

@bors try

[bors]

⌛ Trying commit a0359c8 with merge 2466b92...

[bors]

☀️ Try build successful - checks-actions
Build commit: 2466b92 (2466b92ed5feb282a98bb984f45d1e6d39f8c1aa)

[compiler-errors]

@craterbot check

[craterbot]

👌 Experiment pr-124592 created and queued.
🤖 Automatically detected try build 2466b92
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🚧 Experiment pr-124592 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🎉 Experiment pr-124592 is completed!
📊 51 regressed and 4 fixed (444840 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the blacklist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[fmease]

📊 51 regressed and 4 fixed (444840 total)

Minimizations:

1. tc-collection
   • Minimized (playground)
   • Error message of MIN differs slightly cmp'ed to ORIG but that's not substantial
     • We still have a u64 / T mismatch
2. Andlon/ice_testcase
   • Already tracked in tests/ui/associated-item/issue-105449.rs
3. droundy/sad-monte-carlo
   • Minimized (playground)
4. imgui
   • Minimized (playground)
5. 47 “unknown” build failures
   • TODO(fmease)

[fmease]

@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.

[lcnr]

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

• at least one applicable global ParamEnv candidate
• exactly one applicable non-global ParamEnv candidate
• less than 2 or 3 (depending of the order of where-clauses) impl candidates

With 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:

rust/compiler/rustc_trait_selection/src/traits/select/mod.rs

Lines 498 to 508 in cf2baaa

	let should_drop_i = (0..candidates.len()).filter(|&j| i != j).any(|j| {
	self.candidate_should_be_dropped_in_favor_of(
	&candidates[i],
	&candidates[j],
	has_non_region_infer,
	) == DropVictim::Yes
	});
	if should_drop_i {
	debug!(candidate = ?candidates[i], "Dropping candidate #{}/{}", i, candidates.len());
	candidates.swap_remove(i);
	} else {

This causes the following patterns to change behavior

• https://github.com/rust-lang/rust/blob/2017214dbd8380b58c9b95d95e6e867c746b40ee/tests/ui/traits/winnowing/global-non-global-env-1.rs
• https://github.com/rust-lang/rust/blob/2017214dbd8380b58c9b95d95e6e867c746b40ee/tests/ui/traits/winnowing/global-non-global-env-3.rs

while keeping the behavior of the patterns in

• https://github.com/rust-lang/rust/blob/2017214dbd8380b58c9b95d95e6e867c746b40ee/tests/ui/traits/winnowing/global-non-global-env-2.rs
• https://github.com/rust-lang/rust/blob/2017214dbd8380b58c9b95d95e6e867c746b40ee/tests/ui/traits/winnowing/global-non-global-env-4.rs

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 #124592 (comment). 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

[rfcbot]

Team member @lcnr has proposed to merge this. The next step is review by the rest of the tagged team members:

• @BoxyUwU
• @aliemjay
• @compiler-errors
• @jackh726
• @lcnr
• @nikomatsakis
• @oli-obk
• @spastorino

Concerns:

• could we instead prioritize trivial where-bounds over impls without preventing impls in normalization somehow? (cleanup candidate_should_be_dropped_in_favor_of #124592 (comment))

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.

[BoxyUwU]

is imgui not a relatively significant crate to be breaking? I would expect that to be being used by a lot of projects 🤔

[lcnr]

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

[lcnr]

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

@rfcbot concern could we instead prioritize trivial where-bounds over impls without preventing impls in normalization somehow?

[nikomatsakis]

As I've said a few times, I hope that in the new solver we can convert this to more of a "guidance" setup, but regardless we will need some kind of ordering to give that guidance, and in that vein...

@rfcbot reviewed

...I think this ordering makes intuitive sense. It would be good to work with the regressions (especially imgui) to ensure they update their where-clauses up front, if that is needed, and/or issue point releases.