Stabilize #![no_std]

[steveklabnik]

Previous thread: rust-lang/rust#20537

Now that the runtime is all but gone, no_std's purpose is a bit unclear. It's behind a feature gate, so figuring out exactly what it is and should do is part of the process to get it to be stable.

[kmcallister]

I think the main use case is kernels / bare metal, or any other new platform where you haven't ported std::io etc.

[Virtlink]

Yes, mostly kernels, embedded systems, and other uses where there's no full-fledged libc with I/O and threading.

We should approach this the other way around. Let's first assume Rust doesn't import any runtime crates by default at all (no std, core or prelude). The developer should be able to manually depend on std and set the prelude, or depend on core instead, or on a runtime crate with particular features set, or even on an alternative std implementation provided by a third-party. This only works if the Rust runtime crates (std, core, collections, ..) are no more special than any other crate.

But most developers don't want to choose their runtime, so we should set sensible defaults. The compiler imports std and core by default when building, and perhaps test when testing. However, a different Rust implementation might decide to import completely different runtime crates, again, making std and core no more special than any other crate.

And then the purpose of no_std becomes clear: it's an opt-out of the sensible defaults. The default std, core and prelude should be just for convenience, but it must be just as valid to use any other runtime.

Therefore my opinion is that the attribute should be renamed to no_defaults or something similar, its feature gate should be removed, and it should be usable in Cargo.toml. When no_defaults is specified, none of the runtime crates are ever implicitly imported, in any profile (e.g. dev, release, test). The runtime crates should each get their own Cargo.toml, and should not be treated differently from other crates, making it much easier to cross-compile to a different target or use a different runtime altogether.

[pnkfelix]

Another use case that is important to Rust implementers: Truly minimal test inputs for the compiler when it is in a state where it cannot even successfully compile libcore. (I use it for this quite often...)

[strega-nil]

I am putting my voice to this; it is extremely useful for bare metal programming, and I can't think of a reason that it's behind a feature gate.

[steveklabnik]

I can't think of a reason that it's behind a feature gate.

It's not as clear, post-RT removal, what no_std's purpose actually is. Qualifying exactly that is part of the work that needs to be done. :)

[steveklabnik]

The Reenix paper: http://scialex.github.io/reenix.pdf

has some good insights, specifically on using the standard library in an osdev context

[pythonesque]

It's not as clear, post-RT removal, what no_std's purpose actually is.

It's extremely clear what no_std's purpose is. Take a look at the binary output of even a trivial program with LTO. That's all stuff that many projects either don't want, don't need, or can't use.

Rust not having much of a runtime is great, but it's hardly sufficient--C has even less of a runtime than Rust, but that doesn't mean the Linux kernel can use functionality that relies on libc. It also doesn't mean that every embedded platform that LLVM supports is going to support, to pick an example at random, path munging. Rust's standard library currently makes a lot of assumptions about the system beyond "some sort of allocator exists" (and even then, the largest difficulties Reenix had were dealing with poor behavior from the stdilb allocator). It's also important to be able to define, or opt out of, the behavior of the runtime that Rust does still have (e.g. panics).

[pnkfelix]

Just to be clear: Someone casually reading this thread might think that this issue is some sort of front line to a battle where people are fighting to ensure that #![no_std] persists as a feature.

But as far as I can tell, no one is suggesting that we remove #![no_std]. Even the title of this ticket says "Stabilize ...", not "Decide whether to ..."

Looking at the description for the issue and the linked original thread ( rust-lang/rust#20537 ), the point of this ticket as I understand it is that there used to be many use cases for #![no_std], and now there are fewer. So we need to document the cases that remain.

(Of course, comments listing such use cases will hopefully be useful to such documentation effort; but just saying "I want this feature!" is not going to help the documentation effort.)

[steveklabnik]

Yes, @pnkfelix , you are absolutely correct.

The nature of no_std has changed. In order to stabilize it, its purpose should be clear. We're not trying to say its current purpose isn't useful. but all unstable -> stable transitions need this kind of clear explanation and jsutification.

[briansmith]

@steveklabnik My goal in using no_std in an executable is to ensure that there no code in the final executable except for the code I explicitly provide or use, including crt0, malloc, etc. This is for microcontroller applications. Whether there is a separate no_core flag I need to add too does not matter to me.

My goal in using no_std in a library is to ask the compiler to reject my code if it depends on any code in the standard library--i.e. to help ensure that my library can be safely used in a no_std executable.

[steveklabnik]

This was stabilized in 1.6.