Use a slightly more recent `rustc` toolchain that supports `binrw`

[RyanGlScott]

For reasons that I do not fully understand, nightly-2025-02-16 (the Rust toolchain that mir-json currently requires) cannot build many snippets of code that use the binrw crate. Here is one such example. Given the following project structure:

$ tree .
.
├── Cargo.toml
└── src
    └── lib.rs

2 directories, 2 files

With the following files:

# Cargo.toml
[package]
name = "binrw-example"
version = "0.1.0"
edition = "2024"

[dependencies]
binrw = "=0.15.0"

// src/lib.rs
use binrw::BinRead;

#[derive(BinRead)]
pub struct Point {
    x: i16,
}

If you attempt to build this with the nightly-2025-02-16 toolchain, it will panic at compile time:

$ cargo +nightly-2025-02-16 build
<snip>
   Compiling binrw-example v0.1.0 (/Users/rscott/Documents/Hacking/Rust/binrw-example)
error: proc-macro derive panicked
 --> src/lib.rs:4:10
  |
4 | #[derive(BinRead)]
  |          ^^^^^^^
  |
  = help: message: byte index 3 is out of bounds of `x`

error: could not compile `binrw-example` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...

On the other hand, building this with stable Rust toolchains does not panic, nor does it panic if I pick a more recent nightly toolchain (e.g., nightly-2025-09-02). My hunch is that this was caused by a fleeting rustc compiler bug that was fixed at some point after the nightly-2025-02-16 toolchain was released.

Technically, this is not a mir-json bug, but rather a bug in the underlying toolchain. Still, it is quite annoying that one effectively cannot verify binrw-related code of this sort, so it would be nice if we could bump mir-json to a more recent nightly toolchain that does not suffer from this bug. The first step in doing so would be to figure out what the closest nightly toolchain to nightly-2025-02-16 is that does not suffer from this bug.

[qsctr]

From manually bisecting nightlies, nightly-2025-04-16 seems to be the first one that fixes this.

The thing is that it works on 1.86.0-beta.1 (released 2025-02-18) and 1.86.0 stable (released 2025-04-03), which both branched from the nightly-2025-02-16 toolchain that we are currently using, yet on nightly it didn't get fixed until 2025-04-16. So the bug is probably only triggered by conditionally compiled code for a nightly toolchain (e.g. code that uses unstable features). Based on that, it seems like these conditionally compiled functions later on in the file where the panic originated from could be the culprit.

That code is also gated by a feature flag verbose-backtrace in addition to nightly. The verbose-backtrace and std features are enabled by default, so I tried changing the dependencies section of the Cargo.toml you provided to say

[dependencies]
binrw = { version = "=0.15.0", default-features = false, features = ["std"] }

and sure enough, the code built without errors.

As for what changed between nightly-2025-04-15 and nightly-2025-04-16, the most relevant change I could find is rust-lang/rust#139671. This makes some changes to proc_macro's span API, which then prompted proc-macro2 to make the corresponding changes to its span API, which is in turn used by the chunk of conditionally-compiled code in binrw linked above. However the part of the API which that code uses didn't change.

After some more digging, I think the bug is dtolnay/proc-macro2#522, which is related to this. Basically, even when we are using an older nightly, cargo still installs the latest version of proc-macro2, which is 1.0.103. proc-macro2 tests whether it is being compiled with a nightly toolchain by trying to compile a probe file during its build script which uses the proc_macro span API. The new proc_macro span API introduced in that Rust PR is stabilized as of Rust 1.88.0 stable, so as of proc-macro2 v1.0.100, the build script expects any nightly at all to support the new span API, and so concludes that we are not using a nightly when we build it with nightly-2025-02-16, which still has the old span API. Therefore, since nightly-2025-02-16 is not version 1.88 or later, proc-macro2 implements its span API using a dummy implementation instead of calling the actual proc_macro API. I haven't looked that deeply into the binrw code, but my guess is there is a mismatch in the logic somewhere because binrw is expecting proc-macro2 to return stuff from the real API when compiling with verbose-backtrace && nightly, but proc-macro2 is actually not doing that, and that's what leads to the panic at the runtime of the proc macro. Anyways, I tried using an older version of proc-macro2 before this change was introduced, by doing this instead for the dependencies section of the Cargo.toml

[dependencies]
binrw = "=0.15.0"
proc-macro2 = "=1.0.99"

and it also built successfully.

Do either of these two workarounds work for whatever you're doing with binrw? If so, I'm inclined to say we should do that instead of upgrading to nightly-2025-04-16, because that is far enough from nightly-2025-02-16 that the upgrade will likely be nontrivial, and we should probably focus our efforts on upgrading to the latest version instead.

[RyanGlScott]

Amazing sleuthing!

I am intrigued by the idea of fixing this issue by simply changing the proc2-macro2 version rather than having to upgrade the entire toolchain, which would be a much more expensive fix. I'll try that out on my actual use case and see if that is workable.

[RyanGlScott]

The trick of using binrw <1.0.100 does indeed work on my actual use case! As such, I'll go ahead and close this issue.