#[cfg(no_std)] doesn't work

[Susurrus]

I'm working on a no_std crate that I'd like to test and also compile in a std environment. Working with includes is a little painful right now because #[cfg(no_std)] doesn't seem to work.

As an example, I'd expect the following code to work both with and without no_std (commenting out the first line. Instead, it doesn't work as written below (but will work if you comment out no_std.

#![no_std]

#[cfg(no_std)]
use core::mem;
#[cfg(not(no_std))]
use std::mem;

fn main() {
    let x: u32 = unsafe { mem::uninitialized() };
}

You'll see the following error:

error[E0432]: unresolved import `std::mem`
 --> <anon>:6:5
  |
6 | use std::mem;
  |     ^^^^^^^^ Maybe a missing `extern crate std;`?

In my crate I'd like to do things like keep println!() in my crate for testing during development, but have them work during testing. And also configure the entire module to be no_std when not testing using #![cfg_attr(not(test), no_std)]. Neither of these work because of the current situation.

cc @japaric This is something I mentions in your users forum thread about embedded dev.

[Mark-Simulacrum]

You'll want to add a feature to the crate (std is typical) that conditionally disables no_std. no_std does not itself produce a feature that can be configured on.

So something like:

#![cfg_attr(not(std), no_std)]

#[cfg(not(std))]
use core::mem;
#[cfg(std)]
use std::mem;

fn main() {
    let x: u32 = unsafe { mem::uninitialized() };
}

[TimNN]

@Mark-Simulacrum:

That should probably be #![cfg_attr(not(feature = "std"))]

---

Edit: Nevermind the below, I totally mixed things up

Also, there appears to be a builtin cfg for no_std, try this on the nightly playground:

Code:

#![no_std]
#![feature(lang_items)]

#[lang = "panic_fmt"]
fn foo() {}
#[lang = "eh_personality"]
fn bar() {}

#[cfg(no_std)]
fn main() {}

@Susurrus: Which rust version are you using?

[Susurrus]

@TimNN Did you run that code? I'm seeing the following on the playground:

rustc 1.19.0-nightly (5b13bff52 2017-05-23)
error: main function not found

error: aborting due to previous error

Which is in line with my original code snippet, which I ran in the playground on stable and nightly (hence why I left out lang_items).

[TimNN]

@Susurrus: Oh, I totally mixed things up, please disregard my previous comment.

[japaric]

#[cfg(no_std)] doesn't work

It doesn't work because #[cfg(no_std)] is not a built-in cfg that the compiler recognizes (I grepped the compiler source code; there's no such thing). For instance, this doesn't compile:

#![no_std]

#[cfg(no_std)]
use core::mem;

fn foo() {
    let x: u32 = unsafe { mem::uninitialized() };
}

$ rustc --crate-type=lib foo.rs
error[E0433]: failed to resolve. Use of undeclared type or module `mem`

The proper way to do this is to use a Cargo feature named "std" as @Mark-Simulacrum pointed out.

[Susurrus]

I'm aware it doesn't work now, hence the post! :) My point is why is it this way? Is there a reason this is not supported? I was surprised when I tried to implement it like this that it didn't work, and I've seen it posted in a few other places online that it doesn't, so I'm not the only one.

From this the natural question arises as to why add this functionality if there's already the work around of adding a feature for this? Always a good question and I think the biggest win here is that it eases development of no_std crates, something we really want for embedded to be successful with Rust. This issue arose because of how I approached writing my library. Since there's limited literature in the ecosystem about approaching no_std development, I didn't know any different here. Here were the steps I was taking:

1. Start a lib with no_std enabled and write unit tests of some smaller pieces. Also make an integration test in the form of an example demo.
2. Debugging these tests would be pretty easy if I could just throw in some println!()s.
3. Change #![no_std] to #![cfg_attr(not(test), no_std)]. This lets me set things as no_std for regular builds but then in testing I can use println!(), cool!
4. Run into compilation problems with use std vs use core. Attempt to fix with #[cfg(no_std)]. Compiler silently ignores that directive (I don't know if it should here or not) and things are still broken.

I've also got other issues that arose that make it harder than I think is necessary for writing a dual std/core crate, and maybe this isn't the right approach for the problems I've been running into and a holistic approach with an RFC is the right path forward.

[Mark-Simulacrum]

I agree that writing std/core crates is harder than it should be. no_std shouldn't be magical though. In fact, I don't really understand why that's better than the current approach, #[cfg(not(feature = "std"))], and then configuring std/no_std on the command line.

[Susurrus]

I don't know why no_std shouldn't be magical, it already is. The whole core/std injection this is pretty magical from my point of view.

I think there's a case to be made here to try and flesh out the no_std ecosystem by making it super easy to write crates that work in both.

As an embedded developer it's always a pain trying to find an "embedded" version of a lib. The fact that it's harder to write a no_std crate than not (as most people want to use it with std) is only continuing that problem, when I think there's a real chance to fix it.

I have a bunch of other thoughts on this, so maybe opening this issue was premature. I thought this was a simple consistency/principle-of-least-surprise kind of fix that wouldn't see much debate. This has also opened a can of worms in my mind about how we can drastically improve embedded dev ergonomics with Rust, of which this is just a small piece. I'll post here with a link once I post on internals.

[Mark-Simulacrum]

Well, #![no_std] is a special case, yes, but to my knowledge we don't yet have any special cases in #[cfg(...)] and I'd want to keep it that way if possible. I would love to see work on expanding no_std and making it easier, though.

[japaric]

I'm aware it doesn't work now, hence the post!

Oh, sorry. Since you opened this issue in rust-lang/rust I thought it was a bug report. rust-lang/rfcs would have been more appropriate.

In any case I'm not convinced that cfg(not_std) makes sense. You can't flip no_std from the command line (or at least that's the impression I get from how you want to use it) which is how most the other cfg attributes work (modulo target specific cfgs like cfg(target_env)). So what's the conditional of cfg(not_std): the presence or not of #![no_std] in the current crate?

IMO, if you toggling the #![no_std] attribute on/off you already are using some conditional to do that -- #[cfg(test)] in your case -- so I think you should use that conditional (cfg(test)) instead of an hypothetical cfg(not_std). TL;DR you already are using a conditional (cfg(test)) why do you want another conditional (cfg(test)) that does the same thing? Note that the same reasoning applies if you are using cfg(feature = "std") instead of cfg(test).

[Susurrus]

I agree with what's been stated here, so closing.

[gnzlbg]

I have a macro that calls mem::forget. I export this macro in crate A, which is #[no_std]

I want to use the macro in crate B, which has std, and crate C, which is also #[no_std].

I also want to use the macro in tests and doc tests of crate A, which have std.

The feature = "std" workaround doesn't really help me in all these cases, so my crate A now re-exports mem::forget to be able to call it as $crate::my_mem_forget.

I personally think this is horrible: there should be a way to detect whether std is present, or a $core magic variable so that $core::mem::forget can be used in macros.

[MSxDOS]

I agree there should be an internal way to define whether a standard or core library is being used...