Renaming serde via `package =` in Cargo.toml breaks `#[derive(Deserialize, Serialize)]`

[plaidfinch]

Why this might matter

If a crate depending on serde wants to have a feature whose name itself is serde, it's necessary to rename the serde crate to avoid a feature/crate name conflict, like so:

Cargo.toml:

[package]
name = "serde-derive-bug"
version = "0.1.0"
edition = "2018"

[features]
serde = []

[dependencies]
serde-by-some-other-name = { package = "serde", version = "1", features = ["derive"] }

What goes wrong

However, this causes #[derive(Deserialize)] and #[derive(Serialize)] to break. Suppose we try:

src/lib.rs:

use serde_by_some_other_name::{Serialize, Deserialize};

#[derive(Serialize)]
#[derive(Deserialize)]
struct Something;

Although the imports of the derive macros succeed, the macros return the following compile errors:

error[E0463]: can't find crate for `serde`
 --> src/lib.rs:4:10
  |
4 | #[derive(Deserialize)]
  |          ^^^^^^^^^^^ can't find crate
  |
  = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0463]: can't find crate for `serde`
 --> src/lib.rs:3:10
  |
3 | #[derive(Serialize)]
  |          ^^^^^^^^^ can't find crate
  |
  = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

The two errors cannot be triggered simultaneously because it appears compilation aborts at the first such error, even if the derive attributes are placed on totally separate structs. Commenting out one line or the other causes the remaining error to present itself.

As far as I can tell, there is no way to rename serde to another name using package = ... while preserving the ability to use #[derive(Deserialize, Serialize)]. Is there a workaround for this limitation?

[MikailBag]

I think #[serde(crate = "serde_by_some_other_name")] should work.

[plaidfinch]

Thank you, @MikailBag!

[Mingun]

@kwf, I think you may close this issue