Resolver: Batched Import Resolution

[LorrensP-2158466]

Transforms the current algorithm for resolving imports to a batched algorithm. Every import in the indeterminate_imports set is resolved in isolation. This is the only real difference from the current algorithm.

r? petrochenkov

[LorrensP-2158466]

Code looks a little better now and should be more correct than the previous commits, but I have yet to find a way to resolve the current test failures.

[LorrensP-2158466]

Okey, I did fix core not being built, but those other errors happened again. We now resolve the prelude import path when we create such an import at build_reduced_graph phase.

[petrochenkov]

Could you update the tests to make CI green, so I can see the difference?
(Even if the changes do not seem correct.)

[LorrensP-2158466]

This one is definitely wrong.

[LorrensP-2158466]

This one is wrong as well.

[petrochenkov]

Moving prelude_import processing to build_reduced_graph may also be necessary for #139493.

[LorrensP-2158466]

I'll create a pr for it.

[petrochenkov]

Maybe the commit loop will have to be split into two loops, the first one just setting glob_importers (maybe also imported_module or something else), and the second one doing everything else.

[LorrensP-2158466]

The libcore errors appear when glob_importers are moved from resolve_glob_import to commit (the last commit 5583ebc in master...petrochenkov:rust:batched-import-resolution).

I do not entirely agree with this. The errors started happening when we began using SideEffect and applying them in order of resolution, instead of separately applying the side effects (see a52656d). But yeah, those changes were necessary, because there were failing UI tests.

Reverting those changes did not resolve some of the errors; it even introduced new ones.

Try minimizing core into a small #![no_core] crate that reproduces the problem.

I've not been successful with this, but I should be getting close.

Maybe the commit loop will have to be split into two loops, the first one just setting glob_importers (maybe also imported_module or something else), and the second one doing everything else.

Thought of that as well, and this produces other errors.

I've also noticed that meddling with the commit order produces a lot of different errors that make no more sense than the current ones.

The most successful I've been in producing as few errors as possible is by first committing the glob side effects and then the single import side effects. The only errors that stay present are resolutions made of protable_simd types.

[LorrensP-2158466]

Try tracing accesses to glob_importers before and after that commit to understand what happens.
Try minimizing core into a small #![no_core] crate that reproduces the problem.

Currently doing this.

[petrochenkov]

Suggested change

	self: &mut CmResolver<'r, 'ra, 'tcx>,
	&self,

[petrochenkov]

Suggested change

	self: &mut CmResolver<'r, 'ra, 'tcx>,
	&self,

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

[LorrensP-2158466]

Original resolver errors are resolved, but...
Compiling libcore now fails where some traits are not implemented for some types, but the code does implement them. Most notable Copy, I have a feeling its derive macro is not being resolved correctly.