No global memory allocator error when testing no_std crate that does link to std

[IsaacWoods]

I have a no_std crate that imports std when testing:

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

extern crate alloc;

#[cfg(test)]
#[macro_use]
extern crate std;

However, I get this error during testing:

error: no global memory allocator found but one is required; link to std or add #[global_allocator] t
o a static item that implements the GlobalAlloc trait.

Allocating on the heap during testing does appear to work, so I'm assuming this is just a case of the warning still being emitted.

[zesterer]

I have the same issue. Any update?

[sfackler]

cargo test builds the crate both as a library (for doctests) and as a test executable. You only pull in std for the test executable, so the error message could be coming from building as a library.

[cbeck88]

I have the same issue, error message seems to be spurious

[dvdhrm]

Yeah, the error message is emitted when building the doctest library. Funnily enough, it does not cause the build to fail. That is, cargo test still continues running and then exits with success (0).

Sadly, there is currently no way to link in a default allocator (or std for that matter) for doctests. There is the unstable doc_cfg feature that provides cfg(rustdoc), but I don't see how to achieve something similar without relying on unstable features.

I simply use doctest = false until this is fixed.

[RalfJung]

Related: #52243

[jethrogb]

@rustbot modify labels: +T-rustdoc

[rustbot]

Error: Parsing label command in comment failed: ...ify labels|error: must have : or to as label starter at >| +T-rustdo...

Please let @rust-lang/release know if you're having trouble with this bot.

[Nemo157]

Sadly, there is currently no way to link in a default allocator (or std for that matter) for doctests.

If you don't put #[no_std] inside the doctest it will be linked against std even when testing a #[no_std] crate, you can think of each doctest as a separate crate. If you do want a different allocator you can add a #[global_allocator] static like in a normal binary. Even though this error message is printed the doc tests should still be running.

[RalfJung]

Also see #52243 (comment): the error is basically spurious.