zerocopy-0.8.25 no longer builds on nightly

[VorpalBlade]

Code

I tried this code:

$ cargo new reproducer
$ cd reproducer
$ cargo add zerocopy@=0.8.25 
$ cargo +nightly build
    Updating crates.io index
     Locking 2 packages to latest Rust 1.90.0-nightly compatible versions
 Downgrading zerocopy v0.8.26 -> v0.8.25 (available: v0.8.26)
 Downgrading zerocopy-derive v0.8.26 -> v0.8.25 (available: v0.8.26)
   Compiling zerocopy v0.8.25
error[E0428]: the name `_` is defined multiple times
   --> /home/user/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/zerocopy-0.8.25/src/byteorder.rs:497:9
    |
497 |           const _: () = unsafe {
    |           ^^^^^^^^^^^^^^^^^^^^ `_` redefined here
...
734 | / define_type!(
735 | |     A,
736 | |     "A 64-bit unsigned integer",
737 | |     U64,
...   |
749 | |     [U128]
750 | | );
    | |_- in this macro invocation
    |
   ::: /home/user/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/zerocopy-0.8.25/src/util/macros.rs:416:9
    |
416 |           const _: () = {
    |           ------------- previous definition of the value `_` here
    |
    = note: `_` must be defined only once in the value namespace of this module
    = note: this error originates in the macro `define_type` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0428`.
error: could not compile `zerocopy` (lib) due to 1 previous error

I expected to see this happen: Build on nightly without having to update lock files. This will break so many cargo install --locked commands. For example: requiring me to make a new release for my Arch Linux package just for the package to keep working (even though the software hasn't changed otherwise, it is feature complete).

Instead, this happened: Build error as seen above.

zerocopy 0.8.26 does work, but again, that means every downstream binary project needs to release a new version so cargo install --locked keeps working.

Version it worked on

It most recently worked on:

rustc 1.88.0 (6b00bc388 2025-06-23)
binary: rustc
commit-hash: 6b00bc3880198600130e1cf62b8f8a93494488cc
commit-date: 2025-06-23
host: x86_64-unknown-linux-gnu
release: 1.88.0
LLVM version: 20.1.5

Also checked, it works on beta (1.89.0-beta.5).

Version with regression

rustc --version --verbose:

rustc 1.90.0-nightly (8f08b3a32 2025-07-18)
binary: rustc
commit-hash: 8f08b3a32478b8d0507732800ecb548a76e0fd0c
commit-date: 2025-07-18
host: x86_64-unknown-linux-gnu
release: 1.90.0-nightly
LLVM version: 20.1.8

Backtrace

N/A

@rustbot modify labels: +regression-from-stable-to-nightly -regression-untriaged

[Noratrieb]

Thank you for the report! It would be useful to bisect the regression using cargo-bisect-rustc to make it easier to figure out what happened and ping the relevant people.
@rustbot label E-needs-bisection

[VorpalBlade]

@Noratrieb Sure I can give bisection a go. Never done rustc bisection before though. I see it takes dates, how do I figure out what nightly date beta corresponds to? As that is the latest known working version.

[lqd]

That's #144013, cc author @petrochenkov.

@rustbot label -E-needs-bisection

[VorpalBlade]

I tested a few random dates to find a starting point (I would still like to know a principled approach to this).

Regression starts with nightly-2025-07-19 (2025-07-18 works).

And then it gave the more detailed response:

Regression in b5df05d. Note that if it is a legacy rollup build, it might be available in rust-lang-ci@b5df05d.
The PR introducing the regression in this rollup is #144013: resolve: Make disambiguators for underscore bindings module…

searched nightlies: from nightly-2025-07-18 to nightly-2025-07-19
regressed nightly: nightly-2025-07-19
searched commit range: e466296...8f08b3a
regressed commit: 8231065

bisected with cargo-bisect-rustc v0.6.10

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc --start=2025-07-18 --end=2025-07-19 

[matthiaskrgr]

#144013 might be related cc @petrochenkov

[VorpalBlade]

#144013 might be related cc @petrochenkov

You aren't wrong, but you are late to party.

[matthiaskrgr]

ah i only looked at the bisect output :D