Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"can't find crate for _serde" when deriving #856

Closed
torkleyy opened this issue Apr 8, 2017 · 13 comments
Closed

"can't find crate for _serde" when deriving #856

torkleyy opened this issue Apr 8, 2017 · 13 comments
Labels

Comments

@torkleyy
Copy link

torkleyy commented Apr 8, 2017

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
Copy link
Member

dtolnay commented Apr 8, 2017

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

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

@torkleyy
Copy link
Author

torkleyy commented Apr 8, 2017

@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
Copy link
Member

dtolnay commented Apr 8, 2017

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

@dtolnay dtolnay added the support label Apr 9, 2017
@dtolnay dtolnay closed this as completed Apr 9, 2017
@ishitatsuyuki
Copy link

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
Copy link
Member

dtolnay commented Aug 28, 2017

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

@GildedHonour
Copy link

I don't understand, how to fix it?

@ishitatsuyuki
Copy link

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

@GildedHonour
Copy link

yabai yo!

@kardeiz
Copy link

kardeiz commented Sep 20, 2017

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
Copy link

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

@elichai
Copy link

elichai commented Jan 27, 2019

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)]

@Felabs1
Copy link

Felabs1 commented Jul 20, 2022

how could we use it in web assembly

@Venryx
Copy link

Venryx commented Aug 27, 2022

Just wanted to mention that there is a solution/workaround someone found here: #1465 (comment)

use common::serde::{self, Deserialize, Serialize}

#[derive(Copy, Clone, Debug, Deserialize, Serialize)]
#[serde(crate = "self::serde")] // must be below the derive attribute
struct Vertex {
    position: [u32; 3],
}

I've been using it, and it seems to work fine. (the extra line for each derive usage is not the greatest, but it works -- and is better than adding an extraneous dependency on serde, for each crate utilizing the common crate)

@serde-rs serde-rs locked and limited conversation to collaborators Aug 27, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Development

No branches or pull requests

8 participants