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.

[LorrensP-2158466]

I have no idea why these errors are still thrown. It has to do with the structure of the modules where we import Debug and Hash from.

// Separate module to reexport the macro `Debug` from prelude without the trait `Debug`.
pub(crate) mod macros {
    /// Derive macro generating an impl of the trait `Debug`.
    pub macro Debug($item:item) {
        /* compiler built-in */
    }
}
pub use macros::Debug;

Same with `simd.

mod core_simd;

#[unstable(feature = "portable_simd", issue = "86656")]
pub mod simd {
    pub use crate::core_simd::simd::*;
}

But it's pretty hard to debug this. Maybe you know a way? Or have a separate set of eyes look at this?

And then there are mem::size_of, mem::drop, mem::align_of, ... .

Edit, is it possible this comment above mod simd has something to do with it?

// Pull in the `core_simd` crate directly into core. The contents of
// `core_simd` are in a different repository: rust-lang/portable-simd.
//
// `core_simd` depends on core, but the contents of this module are
// set up in such a way that directly pulling it here works such that the
// crate uses this crate as its core.

[petrochenkov]

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

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

[LorrensP-2158466]

This does require some type of cm() on a &Resolver instead of a `&mut Resolver.

[petrochenkov]

This requires a &self version of per_ns.
per_ns(&self)/per_ns_mut(&mut self), plus per_ns_cm(self: CmResolver) if it's still used.

[LorrensP-2158466]

I'm sorry, I don't understand what you mean. I can't figure out how to pass a &Resolver to resolve_imports and then easily convert it to a CmResolver.

[petrochenkov]

I mean nothing in resolve_import should require &mut Resolver or CmResolver, only &Resolver.

[LorrensP-2158466]

That defeats the purpose of CmResolver, no? maybe_resolve_path and maybe_resolve_ident_in_module require a CmResolver. How do you expect me to change those? I could rename them to spec_* and use CmResolver in those functions.
Sorry for still not understanding.

[petrochenkov]

Wait, how did I do it on my branch https://github.com/petrochenkov/rust/tree/batched-import-resolution then.

[petrochenkov]

Ah, alright, resolve_glob_import can use &self, resolve_import cannot.

resolve_import can use CmResolver by value though.
&mut CmResolver almost never makes sense, because CmResolver is already a reference, you can search for other uses of &mut CmResolver and can try eliminating them.

[LorrensP-2158466]

You changed resolve_glob_import but resolve_import still gets a CmResolver. That's a good change, but i think resolve_import is how it should be for now.

[LorrensP-2158466]

resolve_import can use CmResolver by value though.
&mut CmResolver almost never makes sense, because CmResolver is already a reference, you can search for other uses of &mut CmResolver and can try eliminating them.

Oh right, thats true, thanks!

[petrochenkov]

Suggested change

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

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

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

Some tests get different or duplicate errors on some lines. Not sure why this is yet.

[LorrensP-2158466]

Had to bless/change a lot of tests, but they all look like duplicates; I didn't spot anything wrong going on.

[petrochenkov]

Had to bless/change a lot of tests, but they all look like duplicates; I didn't spot anything wrong going on.

Answered on zulip about this.

[petrochenkov]

We push determined_imports both here and above in resolve_imports, that's where the duplication is coming from, most likely.