[GH-ISSUE #387] Using rustc-serialize #123

New issue

Closed

opened 2026-02-27 20:23:15 +03:00 by kerem · 1 comment

kerem commented

2026-02-27 20:23:15 +03:00

Owner

Originally created by @aplanas on GitHub (Feb 2, 2023).
Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/387

The crate rspotify and rspotify-model are depending on chrono, and the Cargo.toml of both craters are enabling the optional rustc-serialize feature of chrono, dragging it into the dependency tree. Seems that rustc-serialize eventually rustc will refuse to compile it:

warning: the following packages contain code that will be rejected by a future version of Rust: rustc-serialize v0.3.24
note: to see what the problems were, use the option `--future-incompat-report`, or run `cargo report future-incompatibilities --id 1`

The package `rustc-serialize v0.3.24` currently triggers the following future incompatibility lints:
> warning: impl method assumes more implied bounds than the corresponding trait method
>     --> /home/aplanas/.cargo/registry/src/github.com-1ecc6299db9ec823/rustc-serialize-0.3.24/src/serialize.rs:1155:41
>      |
> 1155 |     fn decode<D: Decoder>(d: &mut D) -> Result<Cow<'static, T>, D::Error> {
>      |                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: replace this type to make the impl signature compatible: `Result<Cow<'a, T>, <D as serialize::Decoder>::Error>`
>      |
>      = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
>      = note: for more information, see issue #105572 <https://github.com/rust-lang/rust/issues/105572>
>      = note: `#[allow(implied_bounds_entailment)]` on by default
>

IIUC this means this crate will not be possible to compile in the future.

Maybe the fix is to replace https://github.com/ramsayleung/rspotify/blob/master/Cargo.toml#L36 with

chrono = { version = "0.4.19", features = ["serde"] }

And a similar change in rspotify-model Cargo.toml

Originally created by @aplanas on GitHub (Feb 2, 2023). Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/387 The crate rspotify and rspotify-model are depending on chrono, and the Cargo.toml of both craters are enabling the optional rustc-serialize feature of chrono, dragging it into the dependency tree. Seems that rustc-serialize eventually rustc will refuse to compile it: ``` warning: the following packages contain code that will be rejected by a future version of Rust: rustc-serialize v0.3.24 note: to see what the problems were, use the option `--future-incompat-report`, or run `cargo report future-incompatibilities --id 1` ``` ``` The package `rustc-serialize v0.3.24` currently triggers the following future incompatibility lints: > warning: impl method assumes more implied bounds than the corresponding trait method > --> /home/aplanas/.cargo/registry/src/github.com-1ecc6299db9ec823/rustc-serialize-0.3.24/src/serialize.rs:1155:41 > | > 1155 | fn decode<D: Decoder>(d: &mut D) -> Result<Cow<'static, T>, D::Error> { > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: replace this type to make the impl signature compatible: `Result<Cow<'a, T>, <D as serialize::Decoder>::Error>` > | > = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! > = note: for more information, see issue #105572 <https://github.com/rust-lang/rust/issues/105572> > = note: `#[allow(implied_bounds_entailment)]` on by default > ``` IIUC this means this crate will not be possible to compile in the future. Maybe the fix is to replace https://github.com/ramsayleung/rspotify/blob/master/Cargo.toml#L36 with chrono = { version = "0.4.19", features = ["serde"] } And a similar change in rspotify-model Cargo.toml

kerem

2026-02-27 20:23:15 +03:00

closed this issue
added the
help wanted

bug
labels

kerem commented

2026-02-27 20:23:15 +03:00

Author

Owner

@Kurtsley commented on GitHub (Feb 3, 2023):

It looks like this can be done with absolutely no adverse effects. Nothing needs to be re-written.

@Kurtsley commented on GitHub (Feb 3, 2023): It looks like this can be done with absolutely no adverse effects. Nothing needs to be re-written.

kerem referenced this issue

2026-02-27 20:23:59 +03:00

[PR #123] [MERGED] Replace failure with anyhow and thiserror #258