Serde: "can't find crate for _serde" when deriving

[torkleyy]

If I only include serde_derive in my Cargo.toml, I'll get an

error[E0463]: can't find crate for `_serde`
 --> src/main.rs:4:10
  |
4 | #[derive(Serialize)]
  |          ^^^^^^^^^ can't find crate

error: aborting due to previous error

This is the source code:

#[macro_use]
extern crate serde_derive;

#[derive(Serialize)]
struct Foo;

fn main() {

}

Adding serde to my dependencies fixes this.

Is this a known issue?

[dtolnay]

Thanks for the report! Yes, adding serde to Cargo.toml is one of the setup steps in https://serde.rs/codegen.html.

I pushed 2c49f9aad33009b9f468ce51388852fa0ae31dac to add extern crate serde to the example code even though it is not required, to hopefully remind people.

[torkleyy]

@dtolnay OK, I thought so. The reason I mention this is because together with toml-rs, this causes cargo check to panic. I'm not quite sure why it does that, but the following project causes an ICE:

tree

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

Cargo.toml

[package]
name = "issue-lib"
version = "0.1.0"

[dependencies]
serde_derive = "0.9"
toml = "0.3"

lib.rs

#[macro_use]
extern crate serde_derive;
extern crate toml;

#[derive(Deserialize)]
pub struct Foo {
}

Backtrace

thread 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libcore/option.rs:323
stack backtrace:
   1:     0x7fd6f640240c - std::sys::imp::backtrace::tracing::imp::write::hf33ae72d0baa11ed
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:42
   2:     0x7fd6f64109ae - std::panicking::default_hook::{{closure}}::h59672b733cc6a455
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:351
   3:     0x7fd6f6410553 - std::panicking::default_hook::h1670459d2f3f8843
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:361
   4:     0x7fd6f6410e4b - std::panicking::rust_panic_with_hook::hcf0ddb069e7beee7
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:555
   5:     0x7fd6f6410ce4 - std::panicking::begin_panic::hd6eb68e27bdf6140
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:517
   6:     0x7fd6f6410c09 - std::panicking::begin_panic_fmt::hfea5965948b877f8
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:501
   7:     0x7fd6f6410b97 - rust_begin_unwind
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:477
   8:     0x7fd6f644dedd - core::panicking::panic_fmt::hc0f6d7b2c300cdd9
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libcore/panicking.rs:69
   9:     0x7fd6f644de14 - core::panicking::panic::h7abeb5b818ec354e
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libcore/panicking.rs:49
  10:     0x7fd6f40d1876 - rustc_metadata::creader::CrateLoader::resolve_crate::h6e72600e2dd6f65b
  11:     0x7fd6f40d898f - <rustc_metadata::creader::CrateLoader<'a> as rustc::middle::cstore::CrateLoader>::process_item::h3593d13570805f47
  12:     0x7fd6f38f88b0 - rustc_resolve::build_reduced_graph::<impl rustc_resolve::Resolver<'a>>::build_reduced_graph_for_item::h3cc2f08d7828c563
  13:     0x7fd6f38ff67f - <rustc_resolve::build_reduced_graph::BuildReducedGraphVisitor<'a, 'b> as syntax::visit::Visitor<'a>>::visit_item::h775ca4c5a23a8667
  14:     0x7fd6f39007be - <rustc_resolve::build_reduced_graph::BuildReducedGraphVisitor<'a, 'b> as syntax::visit::Visitor<'a>>::visit_block::h7db730fc3ea01c86
  15:     0x7fd6f38ffb48 - <rustc_resolve::build_reduced_graph::BuildReducedGraphVisitor<'a, 'b> as syntax::visit::Visitor<'a>>::visit_item::h775ca4c5a23a8667
  16:     0x7fd6f38f35bf - rustc_resolve::macros::<impl syntax::ext::base::Resolver for rustc_resolve::Resolver<'a>>::visit_expansion::hc836a3e7268abdbf
  17:     0x7fd6efd9177a - syntax::ext::expand::MacroExpander::collect_invocations::h32417ac98c0c9be1
  18:     0x7fd6efd908dc - syntax::ext::expand::MacroExpander::expand::h695353fd58aabfd3
  19:     0x7fd6efd8fba5 - syntax::ext::expand::MacroExpander::expand_crate::h9811866201c8237a
  20:     0x7fd6f679d0dc - rustc_driver::driver::phase_2_configure_and_expand::{{closure}}::h231d639b5d33e30c
  21:     0x7fd6f67947f5 - rustc_driver::driver::phase_2_configure_and_expand::hd9965365e42d7a90
  22:     0x7fd6f678d43a - rustc_driver::driver::compile_input::hd9f060ee16a643fb
  23:     0x7fd6f67d9844 - rustc_driver::run_compiler::h762802568c0e140e
  24:     0x7fd6f66e5edb - std::panicking::try::do_call::h935e2f773deaf841
  25:     0x7fd6f6419c8a - __rust_maybe_catch_panic
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libpanic_unwind/lib.rs:98
  26:     0x7fd6f670e112 - <F as alloc::boxed::FnBox<A>>::call_box::he43811d1f6894655
  27:     0x7fd6f640f804 - std::sys::imp::thread::Thread::new::thread_start::he668872ac11287ba
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/liballoc/boxed.rs:624
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/sys_common/thread.rs:21
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/sys/unix/thread.rs:84
  28:     0x7fd6eeec96b9 - start_thread
  29:     0x7fd6f60c582c - clone
  30:                0x0 - <unknown>

I would create an issue in the Rust repo for that, but it's not really a minimal example because of its dependencies.

Note: cargo build does not panic

[dtolnay]

Looks like that bug is fixed as of rustc 1.17.0-beta.3 so you don't need to file an issue.

[ishitatsuyuki]

Hey, sorry for bumping. I have enabled unused_extern_crates by default in rust-lang/rust#42588, and stale extern crate will trigger a warning. Can you remove that and try to document it in word instead?

[dtolnay]

Thanks @ishitatsuyuki, I filed https://github.com/serde-rs/serde/issues/1026 and https://github.com/serde-rs/json/issues/350 and https://github.com/serde-rs/serde-rs.github.io/issues/62 to follow up.

[GildedHonour]

I don't understand, how to fix it?

[ishitatsuyuki]

@GildedHonour read the entire thread before bumping. Basically, you need serde as a dependency in your Cargo.toml.

[GildedHonour]

yabai yo!

[kardeiz]

I just encountered this error—

My use case is slightly different. I have a project set up as a Cargo workspace, and I am thinking about setting up an internal common crate to handle external dependencies shared by multiple internal crates. serde and serde_derive are some of those crates I'd like to share.

With the proc_macro feature, I can easily put the Deserialize/Serialize macros in scope wherever I need them. However, if I do so outside the common crate, I get the error in the issue title.

I haven't looked into the internal workings of these macros at all, but I'm guessing they are looking for ::serde (or maybe $crate::serde) in scope. However, in my case serde will be at ::common::serde. Is there any way I can work around this?

[ishitatsuyuki]

@kardeiz No, it only needs a cargo dependency. extern crate is done internally with an alias (_serde).

[elichai]

Hey, This doesn't work with package renaming
Doing serde_std = { package = "serde", version = "1.0", features = ["derive"], optional = true }
Results in error[E0463]: can't find crate for `_serde` for `#[derive(Deserialize)]