proc-macro-crate is not no_std

[diondokter]

The proc-macro-crate pulls in the toml dependency. Toml is not compatible with no_std, so this library transitively isn't either.

[illicitonion]

Thanks for filing an issue! Can I check how this is affecting you?

When we added no_std to this crate, the best research I could find was that crates used during compilation/codegen (like this one) can use std dependencies to do their work, as long as the code they generate doesn't use std. Rustc itself, for instance, uses std, but as long as it doesn't generate any code which depends on std things are fine.

We added a CI job which shows that this crate can be used for targets which lack std: 455e0ee

Is there a particular change you're looking for, or problem you'd like solved?

[diondokter]

So the weird thing is that when I built in a library, it compiled just fine (also embedded). But when using it in an executable, then it complained that that Serde was missing the std libs. I don't know why that is.

I can maybe try again tomorrow and give more info.

Btw, reading back my issue, I came on a bit strong. I was annoyed that it didn't work. Sorry for that!

[illicitonion]

No worries, I totally get that frustration!

If you have any way of sharing a repro case (ideally as minimal as possible), that's be really handy :) Our generated code definitely doesn't have any dependency on serde, but it's certainly possible something weird is happening!

[danielhenrymantilla]

🤔 My guess is that this is due to features being additive (it is related to why Cargo offers [build-dependencies] on top of classic [dependencies], although alas they cannot be used for procedural macros):

• A crate directly depends on serde, but with the std feature disabled.

• It also depends on num_enum, and thus, on proc_macro_crate, which uses serde at build time with the std feature enabled.

• Given that bith are [dependencies], Cargo feature solver decides that serde is indeed required, and that the std feature must be enabled.

• The compiled serde code of the crate thus includes no_std-incompatible artifacts.

---

I guess the solution is to make proc-macro-crate be a (default) feature-enabled dependency @illicitonion

---

EDIT: I have found the following references:

• current status quo: [build-dependencies] and [dependencies] are decoupled, but proc_macros aren't, unless the unstable -Z host_dep cargo flag is used

  • originated from: Features of dependencies are enabled if they're enabled in build-dependencies; breaks no_std libs rust-lang/cargo#5730

• Our situation: Resolution of dependencies should not be affected by the dependencies of procedural-macro-library. rust-lang/cargo#5760

[noonien]

I'm also trying to use this crate to build an elf for an embedded device, and is asking for the std crate.

[mendelt]

Same here. I'm trying to build for thumbv7m-none-eabi and I get an error about not finding std.
Just a thought but this problem seems to be cropping up the last few days while the current version of num_enum is two months old. Might this be a problem the latest version of rust?

[illicitonion]

Thanks @danielhenrymantilla for the solid investigation! Fix in #19

[danielhenrymantilla]

@diondokter @noonien @mendelt can you try adding:

[patch.crates-io.num_enum]
git = "https://github.com/illicitonion/num_enum"
rev = "626dde25383685683f8e785bdbc3bd63a0afe2b5"

to your Cargo.toml and see if that fixes your compilation issue? This is to ensure that #19 is indeed the right fix 🙂

[diondokter]

@danielhenrymantilla Using the patch format in Cargo didn't work, but that may just be a caching error...

I used the following:

num_enum = { git = "https://github.com/illicitonion/num_enum", branch = "serde", default-features = false }

Compilation works just fine now!

[noonien]

Works for me too!

[mendelt]

Works here too

[illicitonion]

Released to crates.io as 0.5.0 :) Thanks all for the reports, investigation, and testing!