regression: a value of type `HashMap<Pulse, u64>` cannot be built from

[BoxyUwU]

• https://crater-reports.s3.amazonaws.com/beta-1.85-1/beta-2025-01-12/gh/dimo414.advent-2023/log.txt

[INFO] [stderr]    Compiling advent-2023 v0.1.0 (/opt/rustwide/workdir)
[INFO] [stdout] error[E0277]: a value of type `HashMap<Pulse, u64>` cannot be built from an iterator over elements of type `&(Pulse, {integer})`
[INFO] [stdout]    --> src/bin/20/main.rs:278:88
[INFO] [stdout]     |
[INFO] [stdout] 278 |           assert_eq!(config.counts, [(Pulse::Low, low), (Pulse::High, high)].into_iter().collect());
[INFO] [stdout]     |                                                                                          ^^^^^^^ value of type `HashMap<Pulse, u64>` cannot be built from `std::iter::Iterator<Item=&(Pulse, {integer})>`
[INFO] [stdout] 279 |       } }

[compiler-errors]

This one seems to have regressed in:

83965ef #133274

cc @ehuss, tho i'll double check when i'm done bisecting the rest

[theemathas]

Minimized (zipped for your convenience: foo.zip):

src/lib.rs

// This crate is in edition 2021

bar::create_macro! {{
    // This code works on edition 2021, but not edition 2018
    let _ = [1i32].into_iter().collect::<Vec<i32>>();
}}
create_fn!();

bar/src/lib.rs

// This crate is in edition 2018

#[macro_export]
macro_rules! create_macro {
    ($body:tt) => {
        macro_rules! create_fn {
            () => {
                fn a() {
                    $body
                }
            };
        }
    };
}

Cargo.toml

[workspace]
members = ["bar"]

[package]
name = "foo"
version = "0.1.0"
edition = "2021"

[dependencies]
bar = { path = "bar" }

bar/Cargo.toml

[package]
edition = "2018"
name = "bar"
version = "0.1.0"

In stable, the function body is compiled as edition 2021. In beta, it is compiled as edition 2018.

For context: This is the intended usage pattern of the parameterized_test crate.

[ehuss]

Hm, yea, I can see how that doesn't look to be working quite as I intended. I would expect substitutions to retain whatever edition the input has, but it makes sense that the macro_rules compiler is ignoring that.

I would be fine reverting #133274 if that is what people want. It did not have a high importance for edition compatibility. I don't recall how many crates would fail in the 2024 edition without it, though. I think it should eventually be fixed, but may require deeper changes if it is possible.

[traviscross]

@rustbot labels -T-libs +T-lang +I-lang-nominated

Let's nominate to sign off on this regression. I talked this one over with @ehuss, and the conclusion we came to is that it's probably best to just accept this if the breakage looks as minimal as what we're seeing here.

Keeping the #133274 PR is helpful to the edition migration, and more broadly, this behavior -- while itself not right either -- at least gives the caller the ability to fix this problem. What it does, essentially, is to leak out to the caller the edition of the crate that defines the macro, but we have of course other places that's also true, e.g.:

• assert_eq! fails with const { .. } in Rust 2024 #133081