Serde msrv got bumped to 1.78 in 1.0.204

[MolotovCherry]

The cargo.toml promises 1.31, but this is no longer true. At least, not with the compiler version I'm using anyways.
rust-version = "1.31"

Perhaps this is expected behavior and serde will just, from now on, be incompatible with all nightly less than 78?

error[E0658]: `#[diagnostic]` attribute name space is experimental
   --> C:\Users\user\.cargo\registry\src\index.crates.io-6f17d22bba15001f\serde-1.0.204\src\de\mod.rs:537:5
    |
537 |     diagnostic::on_unimplemented(
    |     ^^^^^^^^^^
    |
    = note: see issue #111996 <https://github.com/rust-lang/rust/issues/111996> for more information
    = help: add `#![feature(diagnostic_namespace)]` to the crate attributes to enable
    = note: this compiler was built on 2024-02-25; consider upgrading it if it is out of date

[dtolnay]

Most likely, you are building with an old nightly compiler. Old nightlies are not supported in general. You would need to use a more recent nightly compiler, or any stable compiler 1.31 or newer.

[MolotovCherry]

I figured as much. It's quite nice to now have diagnostic on serde. Thanks again for all the hard work you put into your projects! 😄

[dhedey]

@dtolnay / @oli-obk - would we consider updating build.rs so that it recognises the version of nightly builds, and so can avoid new features being enabled when building with older nightly versions?

Just to explain our use case - for one of our builds (a coverage build) we have to use a nightly compiler version, and are blocked on upgrading it because the coverage toolchain is lagging behind most recent rust versions.

Currently a version string such as rustc 1.79.0-nightly (7f2fc33da 2024-04-22) bails out on the u32 conversion and therefore None is returned which gets interpreted as "latest" / "all features enabled":

serde/serde/build.rs

Line 122 in 28a0922

u32::from_str(next).ok()

[oli-obk]

We'd have to detect exact nightly versions, which is very annoying. You can just pin your serde version to an older one until you update your nightly. Unless you're adding a new crate that depends on a newer serde, you won't run into issues that way

[dhedey]

Ahh sorry, I'm just wrong - the logic in build.rs does work when given a nightly version string such as rustc 1.79.0-nightly (7f2fc33da 2024-04-22).

I'm at a bit of a loss why nightly versions don't get the cargo:rustc-cfg=no_diagnostic_namespace option / feature applied then.

But yes, in our case, we can pin serde in our test lock file and use --locked. We have upstream consumers so we can't pin serde in our workspace without creating possibly compatibility problems.

[dtolnay]

I'm at a bit of a loss why nightly versions don't get the cargo:rustc-cfg=no_diagnostic_namespace option / feature applied then.

This would happen if you pick a 1.79 nightly that does not contain the same stable features as 1.79 stable. A request for your coverage toolchains dependency should come out of this (the thing handing you arbitrary old nightly versions they need you to use). You should encourage them to only use nightlies that line up with a beta branch point, i.e. for which the next calendar day's nightly has a higher rustc minor version number, as those contain all the same stable features as the corresponding stable release.

[ArhanChaudhary]

To future lurkers, if you're running into this issue with wasm-pack, you will need to pass --install to use the older versions of serde in the distributed lock file (i.e cargo install --locked wasm-pack@0.13.0)