Rename various resolving functions for consistency, and document them

[jdonszelmann]

r? @lcnr or anyone in @rust-lang/initiative-trait-system-refactor

This is all changes from https://github.com/rust-lang/rust/pull/160913/changes that are just renames. Updating that PR to be just the logic changes

All interesting changes happened in rustc_infer/src/infer/mod.rs across all commits. Everything else is renames propagating through other files.

The functions are now called:

before	after	note
shallow_resolve_*	(unchanged) shallow_resolve_*	Now with newly added docs.
resolve_vars_if_possible_*	deeply_resolve_ignoring_regions_*	deliberately longer name, we want to encourage using deeply_resolve instead.
eager_resolve_vars	deeply_resolve	moved onto the InferCtxtLike as an inherent method with default body.
fully_resolve	(unchanged) deeply_resolve_and_assert_fully_resolved	Resolves with regions and asserts that all variables are resolved at the end. Note, we only use this function 3x so the long name is ok, it shouldn't be your go-to anyway.
opportunistic_resolve_var		gone, same as shalllow_resolve now that we resolve to roots

Note

I've not used an LLM for any part of this PR, or any other PR I make. This includes any related work like research.

[rustbot]

changes to inspect_obligations.rs

cc @lcnr

changes to the core type system

cc @lcnr

Some changes occurred to the core trait solver

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

Some changes occurred in need_type_info.rs

cc @lcnr

[BoxyUwU]

bikeshed: fully_resolve to deeply_resolve_and_assert_blah or sth? it feels odd to me that there wouldnt be a naming similarity between fully_resolve and all the other methods

[jdonszelmann]

hm, I do like that, lemme change that @BoxyUwU :)

[rust-log-analyzer]

The job tidy failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

Diff in /checkout/compiler/rustc_hir_analysis/src/check/compare_impl_item/refine.rs:189:
         return;
     }
     // Resolve any lifetime variables that may have been introduced during normalization.
-    let Ok((trait_bounds, impl_bounds)) = infcx.deeply_resolve_and_assert_fully_resolved((trait_bounds, impl_bounds)) else {
+    let Ok((trait_bounds, impl_bounds)) =
+        infcx.deeply_resolve_and_assert_fully_resolved((trait_bounds, impl_bounds))
+    else {
         // If resolution didn't fully complete, we cannot continue checking RPITIT refinement, and
         // delay a bug as the original code contains load-bearing errors.
         tcx.dcx().delayed_bug("encountered errors when checking RPITIT refinement (resolution)");
fmt: checked 7208 files
Bootstrap failed while executing `test src/tools/tidy tidyselftest --extra-checks=py,cpp,js,spellcheck`
Currently active steps:
test::Tidy {  } at src/bootstrap/src/core/build_steps/test.rs:1666
Build completed unsuccessfully in 0:00:50

[BoxyUwU]

worth moving the trait import to inside this function so we dont actually use other stuff in other functions? 🤔

View changes since the review

[BoxyUwU]

Seems reasonable enough 🤔 It feels a little unfortunate that we lose "var" being in the name of resolve_vars_if_possible. It's also a little unfortunate that deeply_resolve has naming similarities with deeply_normalize which errors if it can't normalize sth, whereas deeply_normalize is fine if it can't resolve something 🤔

I do like the new names more though since they feel more internally consistent with eachother

View changes since this review

[rust-bors]

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