when bailing on ambiguity, don't force other results to ambig by lcnr · Pull Request #155914 · rust-lang/rust

lcnr · 2026-04-28T10:12:06Z

A smaller version of #149904 which doesn't cause the perf issue in bevy, or at least in the minimization

While not necessarily necessary for rust-lang/trait-system-refactor-initiative#257 due to #158643. This does fix the underlying issues there.

This change does affect binius_field, the remaining issues are tracked in rust-lang/trait-system-refactor-initiative#274.

The core idea is that for

A
- B
  - A (cycle with initial result)
B <---

We normally run A until we reach a fixpoint. We don't do so in case trying to do so encounters overflow or the result of A ends up ambiguous to avoid performance issues.

We want to generally keep the provisional cache entries which depend on A around. Evaluating these goals depends on the current provisional result of A. This means it is fine to keep them around if A reached a fixpoint. If we bail without reaching a fixpoint, the provisional result used while computing B differs from the final result of A. This means the entry for B is not valid and we'd need to discard it.

Discarding all nested provisional cache entries when not reaching a fixpoint causes perf issues. In case the final result of A is ambiguous, then this PR keeps nested cache entries which are ambiguous and don't have any inference constraints around. That is sound, as having more goals be ambiguous is never an issue, the trait solver can always say ":shrug: idk". It also shouldn't cause any incorrect ambiguity errors issues, as changing the provisional result of A to be ambiguity should not change B to go from being ambiguous to something else.

The current implementation mutated the result of all nested provisional cache entries to be ambiguous, which resulted in incorrect ambiguity errors in rust-lang/trait-system-refactor-initiative#257. This PR differs from that by dropping goals whose result isn't already ambiguous. That's means we don't keep quite as many cache entries around, which is potentially worse for perf, but from what I can tell this doens't cause issues in practice.

r? BoxyUwU

rustbot · 2026-04-28T10:12:11Z

BoxyUwU is currently at their maximum review capacity.
They may take a while to respond.

lcnr · 2026-04-28T10:12:39Z

@bors try @rust-timer queue

when bailing on ambiguity, don't force other results to ambig

rust-bors · 2026-04-28T12:22:20Z

☀️ Try build successful (CI)
Build commit: 6dcb6cd (6dcb6cdb85235ac3bf5e6e6ac173e11b5cf57ad2, parent: b806d39f033b05ea5aec9a353df75314007a728c)

rust-timer · 2026-04-28T13:02:38Z

Finished benchmarking commit (6dcb6cd): comparison URL.

Overall result: ❌ regressions - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.2%	[0.2%, 0.2%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (secondary 4.8%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.8%	[2.1%, 7.4%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Cycles

Results (secondary -2.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.4%	[-2.4%, -2.4%]	1
All ❌✅ (primary)	-	-	0

Binary size

Results (primary 0.1%, secondary 0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.0%, 0.2%]	49
Regressions ❌ (secondary)	0.1%	[0.0%, 0.2%]	23
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.1%	[0.0%, 0.2%]	49

Bootstrap: 489.748s -> 489.291s (-0.09%)
Artifact size: 393.29 MiB -> 393.40 MiB (0.03%)

BoxyUwU · 2026-06-07T21:15:28Z

i am missing context here, we should sync call about it

@rustbot author

rustbot · 2026-06-07T21:15:31Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

BoxyUwU · 2026-07-22T10:32:06Z

@bors delegate+

r=me after rebase

rust-bors · 2026-07-22T10:32:08Z

✌️ @lcnr, you can now approve this pull request!

If @BoxyUwU told you to "r=me" after making some further change, then please make that change and post @bors r=BoxyUwU.

View changes since this delegation.

BoxyUwU · 2026-07-22T10:32:13Z

@rustbot author

BoxyUwU · 2026-07-22T10:32:46Z

also more PR description :3

rustbot · 2026-07-24T08:04:12Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

lcnr · 2026-07-24T08:16:49Z

@bors r=BoxyUwU rollup (shouldn't have a perf impact for any of our benchmarks)

rust-bors · 2026-07-24T08:16:52Z

📌 Commit 158fdbf has been approved by BoxyUwU

It is now in the queue for this repository.

…=BoxyUwU when bailing on ambiguity, don't force other results to ambig A smaller version of rust-lang#149904 which doesn't cause the perf issue in bevy, or at least in the minimization While not necessarily necessary for rust-lang/trait-system-refactor-initiative#257 due to rust-lang#158643. This does fix the underlying issues there. This change does affect `binius_field`, the remaining issues are tracked in rust-lang/trait-system-refactor-initiative#274. The core idea is that for - A - B - A (cycle with initial result) - B <--- We normally run A until we reach a fixpoint. We don't do so in case trying to do so encounters overflow or the result of `A` ends up ambiguous to avoid performance issues. We want to generally keep the provisional cache entries which depend on A around. Evaluating these goals depends on the current provisional result of A. This means it is fine to keep them around if A reached a fixpoint. If we bail without reaching a fixpoint, the provisional result used while computing B differs from the final result of A. This means the entry for B is not valid and we'd need to discard it. Discarding all nested provisional cache entries when not reaching a fixpoint causes perf issues. In case the final result of A is ambiguous, then this PR keeps nested cache entries which are ambiguous and don't have any inference constraints around. That is sound, as having more goals be ambiguous is never an issue, the trait solver can always say ":shrug: idk". It also shouldn't cause any incorrect ambiguity errors issues, as changing the provisional result of A to be ambiguity should not change B to go from being ambiguous to something else. The current implementation mutated the result of all nested provisional cache entries to be ambiguous, which resulted in incorrect ambiguity errors in rust-lang/trait-system-refactor-initiative#257. This PR differs from that by dropping goals whose result isn't already ambiguous. That's means we don't keep quite as many cache entries around, which is potentially worse for perf, but from what I can tell this doens't cause issues in practice. r? BoxyUwU

Rollup of 3 pull requests Successful merges: - #159740 (reuse regular exported_non_generic_symbols logic in Miri) - #155914 (when bailing on ambiguity, don't force other results to ambig) - #159809 (Avoid `#[target_features]`)

…=BoxyUwU when bailing on ambiguity, don't force other results to ambig A smaller version of rust-lang#149904 which doesn't cause the perf issue in bevy, or at least in the minimization While not necessarily necessary for rust-lang/trait-system-refactor-initiative#257 due to rust-lang#158643. This does fix the underlying issues there. This change does affect `binius_field`, the remaining issues are tracked in rust-lang/trait-system-refactor-initiative#274. The core idea is that for - A - B - A (cycle with initial result) - B <--- We normally run A until we reach a fixpoint. We don't do so in case trying to do so encounters overflow or the result of `A` ends up ambiguous to avoid performance issues. We want to generally keep the provisional cache entries which depend on A around. Evaluating these goals depends on the current provisional result of A. This means it is fine to keep them around if A reached a fixpoint. If we bail without reaching a fixpoint, the provisional result used while computing B differs from the final result of A. This means the entry for B is not valid and we'd need to discard it. Discarding all nested provisional cache entries when not reaching a fixpoint causes perf issues. In case the final result of A is ambiguous, then this PR keeps nested cache entries which are ambiguous and don't have any inference constraints around. That is sound, as having more goals be ambiguous is never an issue, the trait solver can always say ":shrug: idk". It also shouldn't cause any incorrect ambiguity errors issues, as changing the provisional result of A to be ambiguity should not change B to go from being ambiguous to something else. The current implementation mutated the result of all nested provisional cache entries to be ambiguous, which resulted in incorrect ambiguity errors in rust-lang/trait-system-refactor-initiative#257. This PR differs from that by dropping goals whose result isn't already ambiguous. That's means we don't keep quite as many cache entries around, which is potentially worse for perf, but from what I can tell this doens't cause issues in practice. r? BoxyUwU

Rollup of 17 pull requests Successful merges: - #158168 (Added implementation on `set_permissions_nofollow` for all primary platforms) - #138618 (Support using const pointers in asm `const` operand) - #157962 (Function item should not be used as const arg) - #158404 (trait_solver: normalize next-gen region constraints) - #158709 (rustdoc: warn on improperly interleaved HTML/MD) - #159720 (document #[global_allocator] constraints) - #159732 (optimization: don't look for diagnostic/canonical items without rustc_attrs enabled) - #159740 (reuse regular exported_non_generic_symbols logic in Miri) - #159780 (check `extern "custom"` function pointers) - #159786 (rustdoc-js: ignore editor temp files in test folder discovery) - #159819 (std::sync::poison: disable auto_cfg on PoisonError::new) - #155388 (stepping into where-clauses during normalization may be productive) - #155914 (when bailing on ambiguity, don't force other results to ambig) - #159411 ([rustdoc] Correctly handle output options with --show-coverage) - #159439 (Fix(lib/fs/win): Fall back on Win32 delete for `Dir::remove_file`) - #159809 (Avoid `#[target_features]`) - #159826 (Remove redundant `#[rustc_paren_sugar]` feature gate)

…=BoxyUwU when bailing on ambiguity, don't force other results to ambig A smaller version of rust-lang#149904 which doesn't cause the perf issue in bevy, or at least in the minimization While not necessarily necessary for rust-lang/trait-system-refactor-initiative#257 due to rust-lang#158643. This does fix the underlying issues there. This change does affect `binius_field`, the remaining issues are tracked in rust-lang/trait-system-refactor-initiative#274. The core idea is that for - A - B - A (cycle with initial result) - B <--- We normally run A until we reach a fixpoint. We don't do so in case trying to do so encounters overflow or the result of `A` ends up ambiguous to avoid performance issues. We want to generally keep the provisional cache entries which depend on A around. Evaluating these goals depends on the current provisional result of A. This means it is fine to keep them around if A reached a fixpoint. If we bail without reaching a fixpoint, the provisional result used while computing B differs from the final result of A. This means the entry for B is not valid and we'd need to discard it. Discarding all nested provisional cache entries when not reaching a fixpoint causes perf issues. In case the final result of A is ambiguous, then this PR keeps nested cache entries which are ambiguous and don't have any inference constraints around. That is sound, as having more goals be ambiguous is never an issue, the trait solver can always say ":shrug: idk". It also shouldn't cause any incorrect ambiguity errors issues, as changing the provisional result of A to be ambiguity should not change B to go from being ambiguous to something else. The current implementation mutated the result of all nested provisional cache entries to be ambiguous, which resulted in incorrect ambiguity errors in rust-lang/trait-system-refactor-initiative#257. This PR differs from that by dropping goals whose result isn't already ambiguous. That's means we don't keep quite as many cache entries around, which is potentially worse for perf, but from what I can tell this doens't cause issues in practice. r? BoxyUwU

Rollup of 16 pull requests Successful merges: - #138618 (Support using const pointers in asm `const` operand) - #157962 (Function item should not be used as const arg) - #158404 (trait_solver: normalize next-gen region constraints) - #158709 (rustdoc: warn on improperly interleaved HTML/MD) - #159720 (document #[global_allocator] constraints) - #159732 (optimization: don't look for diagnostic/canonical items without rustc_attrs enabled) - #159740 (reuse regular exported_non_generic_symbols logic in Miri) - #159780 (check `extern "custom"` function pointers) - #159786 (rustdoc-js: ignore editor temp files in test folder discovery) - #159819 (std::sync::poison: disable auto_cfg on PoisonError::new) - #155388 (stepping into where-clauses during normalization may be productive) - #155914 (when bailing on ambiguity, don't force other results to ambig) - #159411 ([rustdoc] Correctly handle output options with --show-coverage) - #159439 (Fix(lib/fs/win): Fall back on Win32 delete for `Dir::remove_file`) - #159809 (Avoid `#[target_features]`) - #159826 (Remove redundant `#[rustc_paren_sugar]` feature gate)

…=BoxyUwU when bailing on ambiguity, don't force other results to ambig A smaller version of rust-lang#149904 which doesn't cause the perf issue in bevy, or at least in the minimization While not necessarily necessary for rust-lang/trait-system-refactor-initiative#257 due to rust-lang#158643. This does fix the underlying issues there. This change does affect `binius_field`, the remaining issues are tracked in rust-lang/trait-system-refactor-initiative#274. The core idea is that for - A - B - A (cycle with initial result) - B <--- We normally run A until we reach a fixpoint. We don't do so in case trying to do so encounters overflow or the result of `A` ends up ambiguous to avoid performance issues. We want to generally keep the provisional cache entries which depend on A around. Evaluating these goals depends on the current provisional result of A. This means it is fine to keep them around if A reached a fixpoint. If we bail without reaching a fixpoint, the provisional result used while computing B differs from the final result of A. This means the entry for B is not valid and we'd need to discard it. Discarding all nested provisional cache entries when not reaching a fixpoint causes perf issues. In case the final result of A is ambiguous, then this PR keeps nested cache entries which are ambiguous and don't have any inference constraints around. That is sound, as having more goals be ambiguous is never an issue, the trait solver can always say ":shrug: idk". It also shouldn't cause any incorrect ambiguity errors issues, as changing the provisional result of A to be ambiguity should not change B to go from being ambiguous to something else. The current implementation mutated the result of all nested provisional cache entries to be ambiguous, which resulted in incorrect ambiguity errors in rust-lang/trait-system-refactor-initiative#257. This PR differs from that by dropping goals whose result isn't already ambiguous. That's means we don't keep quite as many cache entries around, which is potentially worse for perf, but from what I can tell this doens't cause issues in practice. r? BoxyUwU

rustbot assigned BoxyUwU Apr 28, 2026

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) labels Apr 28, 2026