Can't ignore soft destabilization of `rustc-serialize` with `#![allow(soft_unstable)]`

[pitdicker]

In chrono we have support for rustc-serialize behind a feature flag.

As a workaround for #116016 I added the line:

#![cfg_attr(feature = "rustc-serialize", allow(deprecated), allow(soft_unstable))]

It now gives a new error:

error[E0658]: use of unstable library feature 'libstd_sys_internals': used by the panic! macro
  --> src/weekday.rs:33:64
   |
33 | #[cfg_attr(feature = "rustc-serialize", derive(RustcEncodable, RustcDecodable))]
   |                                                                ^^^^^^^^^^^^^^
   |
   = help: add `#![feature(libstd_sys_internals)]` to the crate attributes to enable
   = note: this compiler was built on 2024-03-27; consider upgrading it if it is out of date
   = note: this error originates in the derive macro `RustcDecodable` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0658]: use of unstable library feature 'libstd_sys_internals': used by the panic! macro
  --> src/month.rs:32:64
   |
32 | #[cfg_attr(feature = "rustc-serialize", derive(RustcEncodable, RustcDecodable))]
   |                                                                ^^^^^^^^^^^^^^
   |
   = help: add `#![feature(libstd_sys_internals)]` to the crate attributes to enable
   = note: this compiler was built on 2024-03-27; consider upgrading it if it is out of date
   = note: this error originates in the derive macro `RustcDecodable` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0658`.
error: could not compile `chrono` (lib) due to 2 previous errors; 4 warnings emitted

cc @jhpratt

[pitdicker]

The derived Decodable implementation for an enum is using ::std::rt::begin_panic. Manually implementing Decodable and using unreachable!() is a workaround.

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-critical

[ehuss]

cc @jhpratt

[jhpratt]

I'm actually not sure this is a T-libs issue. I suspect it's related to #[allow_internal_unstable], but I haven't had a chance to look into it yet.