Skip to content

Conversation

LorrensP-2158466
Copy link
Contributor

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

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 8, 2025
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@LorrensP-2158466 LorrensP-2158466 marked this pull request as ready for review August 11, 2025 08:37
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 11, 2025
@rust-log-analyzer

This comment has been minimized.

@petrochenkov petrochenkov added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 11, 2025
@LorrensP-2158466
Copy link
Contributor Author

LorrensP-2158466 commented Aug 11, 2025

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.

@rust-log-analyzer

This comment has been minimized.

@LorrensP-2158466
Copy link
Contributor Author

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.

@LorrensP-2158466 LorrensP-2158466 force-pushed the batched-import-resolution branch from a3f8ae2 to 4a2a0dc Compare August 11, 2025 20:37
@rust-log-analyzer

This comment has been minimized.

@petrochenkov
Copy link
Contributor

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

@petrochenkov petrochenkov added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 12, 2025
@petrochenkov
Copy link
Contributor

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

@LorrensP-2158466
Copy link
Contributor Author

I'll create a pr for it.

@LorrensP-2158466 LorrensP-2158466 force-pushed the batched-import-resolution branch from 0eba015 to 0bd2ce4 Compare October 8, 2025 14:13
@rustbot
Copy link
Collaborator

rustbot commented Oct 8, 2025

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
Copy link
Contributor Author

Rebased to get the changes from my previous PR.

@rust-log-analyzer

This comment has been minimized.

@LorrensP-2158466
Copy link
Contributor Author

Ah right, that test.

@LorrensP-2158466
Copy link
Contributor Author

@petrochenkov I have reverted that change in finalize_resolutions_in, so you can run crater on that if needed. In the mean time i'll try and implemented as you suggested in the zulip thread.

@petrochenkov
Copy link
Contributor

@petrochenkov I have reverted that change in finalize_resolutions_in, so you can run crater on that if needed. In the mean time i'll try and implemented as you suggested in the zulip thread.

Please, set the waiting-on-review label if something is needed from me, otherwise it gets lost easily.
@bors try

@rust-bors

This comment has been minimized.

rust-bors bot added a commit that referenced this pull request Oct 9, 2025
…=<try>

Resolver: Batched Import Resolution
@petrochenkov petrochenkov added S-waiting-on-crater Status: Waiting on a crater run to be completed. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 9, 2025
@LorrensP-2158466
Copy link
Contributor Author

Please, set the waiting-on-review label if something is needed from me, otherwise it gets lost easily.

Ah right, sorry!

@rust-bors
Copy link

rust-bors bot commented Oct 9, 2025

☀️ Try build successful (CI)
Build commit: 2278ef2 (2278ef25f90817c20d6dd0d2da58a990eb6f53cb, parent: 0b278a539440be291466ea463a9b6310eaf4d7bb)

@petrochenkov
Copy link
Contributor

@craterbot check

@craterbot
Copy link
Collaborator

👌 Experiment pr-145108-1 created and queued.
🤖 Automatically detected try build 2278ef2
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@craterbot
Copy link
Collaborator

🚧 Experiment pr-145108-1 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@craterbot
Copy link
Collaborator

🎉 Experiment pr-145108-1 is completed!
📊 195 regressed and 3 fixed (713837 total)
📊 1734 spurious results on the retry-regessed-list.txt, consider a retry1 if this is a significant amount.
📰 Open the summary report.

⚠️ If you notice any spurious failure please add them to the denylist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

Footnotes

  1. re-run the experiment with crates=https://crater-reports.s3.amazonaws.com/pr-145108-1/retry-regressed-list.txt

@craterbot craterbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-crater Status: Waiting on a crater run to be completed. labels Oct 11, 2025
rust-cloud-vms bot pushed a commit to makai410/rustc_public that referenced this pull request Oct 12, 2025
…etrochenkov

Test: Ambigious bindings in same namespace with the same res

Add a test based on the discussion [here](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Parallel.20Macro.20Expansion/near/542316157) and related to rust-lang/rust#145575 (comment).

This is the most reduced form I could create that passes on nightly but fails with rust-lang/rust#145108 (see [#gsoc > Project: Parallel Macro Expansion @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Parallel.20Macro.20Expansion/near/542335131)).

Also not sure about the test names.

r? `@petrochenkov`
@LorrensP-2158466
Copy link
Contributor Author

LorrensP-2158466 commented Oct 13, 2025

Almost all regressions are due to the privacy error of RustEmbed or a indirect error because of that privacy error.

I found one other type of regression with some crates using polar-rs 44.2, but I don't understand that one:

error[E0308]: mismatched types
    --> src/occupancy.rs:202:36
[INFO] [stdout]     |
 202 |                       max_horizontal([
     |  _____________________--------------_^
     | |                     |
     | |                     arguments to this function are incorrect
 203 | |                         col("A_pseudo"),
 204 | |                         col("C_pseudo"),
 205 | |                         col("G_pseudo"),
 206 | |                         col("T_pseudo"),
 207 | |                     ])
     | |_____________________^ expected `&[Column]`, found `[Expr; 4]`
     |
     = note: expected reference `&[polars::prelude::Column]`
                    found array `[Expr; 4]`
 note: function defined here
    --> /opt/rustwide/cargo-home/registry/src/index.crates.io-1949cf8c6b5b557f/polars-ops-0.44.2/src/series/ops/horizontal.rs:4:8
     |
   4 | pub fn max_horizontal(s: &[Column]) -> PolarsResult<Option<Column>> {

Looking up col in polar-rs 44.2 results in:

pub fn col(name: &str) -> Expr;

And I haven't found any other definitions of max_horizontal.

Comment on lines 379 to 393
// "Same res different import" ambiguity hack for macros introduced in #145108.
// See related discussion for more info:
// https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Parallel.20Macro.20Expansion/near/542057918.
if ns == MacroNS {
if let Some(def_id) = res.opt_def_id() {
self.greatest_vis_map
.entry(def_id)
.and_modify(|vis| {
if !vis.is_at_least(binding.vis, tcx) {
*vis = binding.vis
}
})
.or_insert(binding.vis);
}
}
Copy link
Contributor Author

@LorrensP-2158466 LorrensP-2158466 Oct 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this also check if the binding is introduced through a glob?

Currently, the case of doing the glob import with a macro also succeeds, which fails on nightly. Can we check whether the expansion IDs match?

@LorrensP-2158466
Copy link
Contributor Author

@rustbot ready

@rust-log-analyzer

This comment has been minimized.

@LorrensP-2158466 LorrensP-2158466 force-pushed the batched-import-resolution branch from 1d22dcc to 3b3d0ed Compare October 13, 2025 17:38
@rust-log-analyzer
Copy link
Collaborator

The job aarch64-gnu-llvm-20-1 failed! Check out the build log: (web) (plain enhanced) (plain)

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

error[E0603]: macro `format_args` is private
    --> /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tracing-0.1.41/src/macros.rs:2961:104
     |
2961 | ...   $crate::valueset!(@ { (&$next, $crate::__macro_support::Option::Some(&$crate::__macro_support::format_args!($($rest)+) as &dyn Valu...
     |                                                                                                      ^^^^^^^^^^^ private macro
     |
note: the macro `format_args` is defined here
    --> /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tracing-0.1.41/src/lib.rs:993:34
     |
 993 |     pub use core::{concat, file, format_args, iter::Iterator, line, option::Option};
     |                                  ^^^^^^^^^^^
help: consider importing this macro instead
     |
2961 -         $crate::valueset!(@ { (&$next, $crate::__macro_support::Option::Some(&$crate::__macro_support::format_args!($($rest)+) as &dyn Value)), $($out),* }, $next, )
2961 +         $crate::valueset!(@ { (&$next, $crate::__macro_support::Option::Some(&std::format_args!($($rest)+) as &dyn Value)), $($out),* }, $next, )
     |
help: import `format_args` directly
     |
2961 -         $crate::valueset!(@ { (&$next, $crate::__macro_support::Option::Some(&$crate::__macro_support::format_args!($($rest)+) as &dyn Value)), $($out),* }, $next, )
2961 +         $crate::valueset!(@ { (&$next, $crate::__macro_support::Option::Some(&core::macros::builtin::format_args!($($rest)+) as &dyn Value)), $($out),* }, $next, )
     |

[RUSTC-TIMING] blake3 test:false 1.228
   Compiling sha1 v0.10.6
[RUSTC-TIMING] sha1 test:false 0.383

@LorrensP-2158466
Copy link
Contributor Author

When running the command of the failing job I get a different error (with latest master rebased):

error[E0603]: macro `cryptocorrosion_derive_traits` is private
   --> /Users/lorrens/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/ppv-lite86-0.2.21/src/soft.rs:8:11
    |
  8 | zerocopy::cryptocorrosion_derive_traits! {
    |           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ private macro
    |
note: the macro `cryptocorrosion_derive_traits` is defined here
   --> /Users/lorrens/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/zerocopy-0.8.26/src/macros.rs:853:1
    |
853 | macro_rules! cryptocorrosion_derive_traits {
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
help: import `cryptocorrosion_derive_traits` directly
    |
  8 | zerocopy::macros::cryptocorrosion_derive_traits! {
    |           ++++++++

Which caused a bunch of other errors. I'm not that experienced with reading those job errors and figuring out what to do (especially with the mismatch locally). Could you point me in the right direction?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

I-lang-radar Items that are on lang's radar and will need eventual work or consideration. 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.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants