Rustdoc: strange issues with `no_std`

[phil-opp]

The following doc test fails:

#![no_std]

use embedded::components::gpio::stm32f7;

fn main() {}

with the error

error: an inner attribute is not permitted in this context
 --> <anon>:2:3
  |
2 | #![no_std]
  |   ^
  |
  = note: inner attributes and doc comments, like `#![no_std]` or `//! My crate`, annotate the item enclosing them, and are usually found at the beginning of source files. Outer attributes and doc comments, like `#[test]` and
                                   `/// My function`, annotate the item following them.

So rustdoc doesn't recognize the no_std attribute.

However, when I add the extern crate definition manually, it works:

#![no_std]

use embedded::components::gpio::stm32f7;

extern crate embedded; // add the import manually

fn main() {}

It also works for imports from core:

#![no_std]

use core::sync; // import something from core (instead of importing from my own crate)

fn main() {}

The strange thing is that it also works if I add a comment containing extern crate:

#![no_std]

use embedded::components::gpio::stm32f7;

// extern crate

fn main() {}

(With "it works" I mean that the no_std attribute is recognized).

---

Edit: I added an example project in at phil-opp/issue-38129 (see the comment below).

[steveklabnik]

So, https://doc.rust-lang.org/stable/book/documentation.html#documentation-as-tests

Any leading #![foo] attributes are left intact as crate attributes.

So I would expect that this error wouldn't happen.

What's truly strange is that trying this out myself, I get the right kind of error:

---- _0 stdout ----
        error[E0432]: unresolved import `foo::bar`
 --> <anon>:2:5
  |
2 | use foo::bar;
  |     ^^^^^^^^ Maybe a missing `extern crate foo`?

error: language item required, but not found: `panic_fmt`

error: language item required, but not found: `eh_personality`

error: language item required, but not found: `eh_unwind_resume`

[phil-opp]

trying this out myself, I get the right kind of error:

These errors are fine, since we're creating a no_std executable. It does mean that the no_std attribute is recognized.

[phil-opp]

I created an example project for this issue at phil-opp/issue-38129. When you run cargo test on it, all 4 tests will fail. However, only the foo test will reject the no_std attribute (the other tests fail because various lang_items are missing in no_std mode).

[durka]

The heuristic for whether to automatically insert extern crate is pretty dumb, it just does a substring search.

[durka]

And it looks like the book

Any leading #![foo] attributes are left intact as crate attributes.

is lying: it only leaves attributes of the form #![feature(foo)]. Ugh, this heuristic is so leaky. I'm not sure whether we should change the docs or change the code.

[durka]

PR submitted.

[Zildj1an]

So what is the workaround if I get this error?