rename select_where_possible and select_all_or_error

[BoxyUwU]

r? @lcnr

I find that people get confused by what these methods do. The verb "select" is not really that helpful and is just a reference to somewhat of an implementation detail of the trait solvers that doesn't even apply to most obligation kinds.

I went with try_evaluate_obligations and evaluate_obligations_error_on_ambiguity. This maintains consistency with the new solvers evalute_goal entry point. it's unfortunate that we say obligations rather than goals but this maintains consistency with register_obligation functions which I think is a good thing. In the long term possibly we rename Obligation or Goal 🤷‍♀️

[rustbot]

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred in engine.rs, potentially modifying the public API of ObligationCtxt.

cc @lcnr, @compiler-errors

Some changes occurred to constck

cc @fee1-dead

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[compiler-errors]

I feel like the "registered" part of these methods names is redundant, and removing it would make the method names appreciably shorter. Not sure if there's any value in being explicit about only evaluating "registered" obligations.

[BoxyUwU]

I've been clippy'd 😔

@compiler-errors I was worried it might imply the methods accept a list of obligations to evaluate, but I think you're right that we could just drop the registered part 🤔 that possibility for confusion is kinda moot given it can immediately be clarified by seeing that there is no list of obligations as an argument and doc comments can explicitly clarify its evaluating stuff that was previously registered 👍

try_evaluate_obligations and evaluate_obligations_or_error is definitely shorter :3

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead.

cc @rust-lang/rust-analyzer

[BoxyUwU]

ah I should revert the r-a changes, I didn't realise r-a had its own fullfillment ctxt impl

[oli-obk]

Could also use prove instead of evaluate.

lgtm

[lnicola]

I should revert the r-a changes

We'll probably want to rename it there, so the code stays closer to what's in rustc.

[lcnr]

i'd go with [try_]evaluate_obligations[or_error]. Talking with @BoxyUwU

• we're using compute and evaluate in the solver to distinguish between "evaluate" as the entry point when evaluating (nested) goals and "compute" for implementation details of "evaluate". Not the best naming, but it's kinda nice to have "u shouldn't use compute_X except for the current goal itself, and only use "evaluate_X" for nested goals.
• I prefer "evaluate" over "prove" as the trait solver also does a bunch of jank which feels surprising when proving something: inference and region constraints etc etc. I don't think we're consistent in any way when talking about this :3

[lcnr]

after looking at it and chatting with Boxy, evaluate_obligations_or_error isn't as explicit about "this errors on ambiguity" as I would like, anbd we've previously had at least 1 unsoundness because we've used the wrong function here.

Please change to

• try_evaluate_obligations
• evaluate_obligations_error_on_ambiguity

@rustbot author

[lcnr]

this is the only try_evaluate_obligations in this function and it feels odd :> ah well

[lcnr]

some nits, then r=me

View changes since this review

[bors]

☔ The latest upstream changes (presumably #147210) made this pull request unmergeable. Please resolve the merge conflicts.

[rustbot]

This PR was rebased onto a different master 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.

[BoxyUwU]

@bors r=lcnr rollup=never

left the r-a changes in due to @lnicola's comment

[bors]

📌 Commit 8e9b0c4 has been approved by lcnr

It is now in the queue for this repository.

[bors]

⌛ Testing commit 8e9b0c4 with merge 4fd3181...

[bors]

☀️ Test successful - checks-actions
Approved by: lcnr
Pushing 4fd3181 to master...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing f6aa851 (parent) -> 4fd3181 (this PR)

Test differences

Show 2 test diffs

2 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 4fd31815524baba0bf368f151f757101f432e3de --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. x86_64-gnu-miri: 5410.9s -> 4354.7s (-19.5%)
2. pr-check-1: 1654.3s -> 1428.5s (-13.7%)
3. dist-x86_64-apple: 8059.4s -> 7050.9s (-12.5%)
4. dist-apple-various: 4131.5s -> 3645.5s (-11.8%)
5. i686-gnu-2: 6195.8s -> 5555.2s (-10.3%)
6. pr-check-2: 2537.5s -> 2298.9s (-9.4%)
7. dist-x86_64-windows-gnullvm: 5219.2s -> 4791.4s (-8.2%)
8. dist-aarch64-msvc: 6146.8s -> 6622.2s (7.7%)
9. x86_64-gnu-llvm-20-1: 3262.8s -> 3514.3s (7.7%)
10. dist-i686-msvc: 8285.7s -> 7656.2s (-7.6%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

[rust-timer]

Finished benchmarking commit (4fd3181): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -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.1%	[0.1%, 0.1%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 0.9%, secondary 5.0%)

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

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

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 472.758s -> 473.366s (0.13%)
Artifact size: 388.40 MiB -> 388.38 MiB (-0.01%)