Prepare revert of 144013

[lqd]

This is a possible revert for #144013 causing issue #144168 (imo p-crit) to give us time to figure out a correct fix for #144013 without pressure. Feel free to close if it's an easy fix instead: r? @petrochenkov

[petrochenkov]

@bors r+

[bors]

📌 Commit 9613ce0 has been approved by petrochenkov

It is now in the queue for this repository.

[petrochenkov]

cc @LorrensP-2158466

[LorrensP-2158466]

I can't seem to reduce #144168, the big and weird macros make it hard. It looks like this will do it, but it does not.:

const _: () = {
    let x= 10;
};

const _: () = {
    let x= 10;
};

I suspect this has something to do with this, but I'm not sure.

let key = BindingKey::new_disambiguated(ident, ns, || {
    (module.0.0.lazy_resolutions.borrow().len() + 1).try_into().unwrap()
});

[lqd]

The exact repro is subtle (you can have many different kinds of errors with slightly different code) and seems to involve const eval failing in a certain manner, and interacting with macros, failing imports, and glob imports.

It's not that hard though.

macro_rules! impl_for_transmute_from {
    () => {
        const _: () = {};
    };
}

mod impls {
    use super::*;
    impl_for_transmute_from!();
    impl_for_transmute_from!();
    const _: () = todo!();
    const _: () = todo!();
    const _: () = todo!();
    const _: () = todo!();
    const _: () = todo!();
}
use X as Y;
use Z as W;
const _: () = todo!();

I'll add it as a test later today (in this PR if it hasn't landed, in another if it has), and don't want to delay this one too much to ensure it hits nightly today.

Bumping prio to avoid rollups, @bors p=6

[LorrensP-2158466]

Oh wow, I would never have come up with that. What are some general tips for minimizing examples? Besides having a good understanding of the compiler :).

[lqd]

I'd never come up with that either, it's just reduced from the crate instead of trying to recreate it 😅. For tips, maybe https://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-patterns/ (and some understanding the compiler is better for recreating MCVEs from scratch, rather than minimizing examples, that's just while !code.is_small_enough() { self.reduce() })

[petrochenkov]

This is likely caused by every resolution in lazy_resolutions having up to 2 entries inside it (glob and non-glob).
So define can fill an empty slot in an existing resolution instead of pushing one more entry into the vector and increasing its size (which is used as the disambiguator).

[LorrensP-2158466]

So BindingKey should have that distinction as well?

[bors]

⌛ Testing commit 9613ce0 with merge 0d95920...

[bors]

☀️ Test successful - checks-actions
Approved by: petrochenkov
Pushing 0d95920 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 f63685d (parent) -> 0d95920 (this PR)

Test differences

Show 4 test diffs

4 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 0d9592026226f5a667a0da60c13b955e0b486a07 --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-apple-1: 8301.4s -> 10393.0s (25.2%)
2. dist-apple-various: 9416.4s -> 7083.9s (-24.8%)
3. dist-x86_64-apple: 10215.2s -> 11155.4s (9.2%)
4. dist-powerpc64le-linux-gnu: 5528.9s -> 5041.4s (-8.8%)
5. x86_64-apple-2: 5174.5s -> 4746.0s (-8.3%)
6. dist-ohos-x86_64: 4447.6s -> 4086.4s (-8.1%)
7. dist-armv7-linux: 5373.5s -> 4967.4s (-7.6%)
8. dist-aarch64-apple: 5103.3s -> 4724.9s (-7.4%)
9. dist-ohos-aarch64: 4418.9s -> 4109.9s (-7.0%)
10. aarch64-gnu: 6304.9s -> 6740.1s (6.9%)

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 (0d95920): 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 2.9%)

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

	mean	range	count
Regressions ❌ (primary)	2.9%	[2.3%, 3.4%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.9%	[2.3%, 3.4%]	2

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: 465.551s -> 465.968s (0.09%)
Artifact size: 374.61 MiB -> 374.57 MiB (-0.01%)