RFC: Stabilize the #![no_std] attribute

[alexcrichton]

Stabilize the #![no_std] attribute while also improving the ergonomics of
using libcore by default. Additionally add a new #![no_core] attribute to opt
out of linking to libcore.

rendered

[eddyb]

These are already special-cased as "weak lang items" so using a mechanism different from regular lang items is not that much of a compromise IMO, but it would be nice if the existing situation was mentioned in the RFC.

[nagisa]

Why?

I really like how current #[lang] works and that it is easy to grep for it, etc. I also believe it would be not too hard to stabilise #[lang="*"] only for certain *. That being said, I 👎 on this part of the RFC.

[eddyb]

They aren't really lang items, but rather a minimal set of compiler-sanctioned weak import/exports.
Libraries could be allowed to define custom "pluggable items" and then these 3 would not be known to the language, just libcore and its users.

[Ericson2314]

Can we avoid stabilizing the lang items but do the rest? That will mean libcore is only stable to use when std is also linked, but I don't think that is a problem (for now). We still get the benefits of making the macros use core, and anybody actually writing kernel code will need unstable core features anyways.

There is a lot of jank in some those lang items as the RFC admits, and eh_personality is somewhat tied to libcompiler/libgcc. Also the fact that the undefined items problem in core and alloc are being defined in two different ways is worrysome---crate level "functors" a la the MLs that any library could use or define or instantiate would be better.

[Tobba]

I propose that extern crate core; should be injected regardless of #![no_std]. This would make it easier to write #![no_std] libraries that contain macros which will work regardless of if the consumer crate is no_std or not.

[Tobba]

What's the rationale behind this change? This was convenient for formatting reasons, and I don't see why it should go.

[alexcrichton]

We don't necessarily want to commit to providing a filename/line number in all panic messages as there have been musings in the past that a measurable overhead in terms of binary size and runtime is incurred from having all these strings/numbers in the binary.

[Tobba]

Both this and stack_exhausted seem like rather bad candidates for stabilization: they're both implementation details of the platform and compiler.

[Tobba]

Proposal: don't stabilize any lang items at all, due to the aforementioned arguments.

One of the current major problems of no_std is that writing libraries that work across both settings is very tedious - it currently involves maintaining a tangled mess of #[cfg] attributes which is rarely tested before release. Stabilizing lang items do nothing to improve this situation anyways.

[thepowersgang]

I agree about not stabilizing any language items here, if this is just for allowing no_std library crates.

However - if stabilizing these language items will allow compilation of no_std binaries (using an externally defined entrypoint, instead of #[start]) then maybe.

[Ericson2314]

Overall, I'm convinced over the long haul we can reduce the complexity of these implementation details (w.g.. with crate functors, stabilized rust without exceptions), so I rather leave them unstable as long as possible. Complexity is worse than instability for the foreseeable future.

[eddyb]

@Tobba I thought $crate solved core/std selection issues in macros.

[Tobba]

@eddyb As far as I know it only works for referencing the current crate.

[petrochenkov]

It doesn't feel right for me that functions deeply internal to Rust are stabilized as extern "C". Is anybody going to import them from C code? Do they need more ABI stability than any other functions?

[alexcrichton]

A possible extension one day could be to allow to define these kinds of lang items in other languages (e.g. C), so I figured it would be nice to have a defined ABI to leave the door open to that possibility.

[nagisa]

This being a diverging function restricts

the implementation of what happens on stack overflow

to terminating the program. I don’t see how you could reallocate a bigger stack and return to normal execution. for example.

[eddyb]

That's not supported, our abuse of segmented stacks will be removed as soon as LLVM gets proper support for stack probes across all platforms.
IIRC there are some patches waiting to be reviewed and merged (cc @Zoxc).

[nagisa]

our abuse of segmented stacks will be removed as soon as LLVM gets proper support for stack probes across all platforms.

Aware. What I’m just pointing out the function doesn’t exactly work as advertised just above it.

On Windows, where this abuse is not done, this “language item” is not used at all, so I’m doubtful this needs to be stabilised.

[alexcrichton]

I agree with @eddyb that there's really no way this function could ever return, adding segmented stacks back is likely to be a much more invasive change than just affecting this function.

[huonw]

We can presumably generalise the signature in future if we find use-cases for other ones.

[steveklabnik]

I would argue that it is paving a way forward, but it's just not there yet. These are the first steps.

[alexcrichton]

@Ericson2314, @Tobba, @thepowersgang

Can we avoid stabilizing the lang items but do the rest?

This is certainly an alternative! (which I have now added) The consequence of this decision is there will be no stable method of producing a staticlib or dylib which uses #![no_std] everywhere. I would personally like to enable this use case as having #![no_std] doesn't seem too useful without it. We can avoid stabilizing the exact signatures with the #![lang_items_abort] alternative mentioned, but there may be other ways to enable the use case of producing a final artifact without defining the precise signatures.

---

@Tobba

I propose that extern crate core; should be injected regardless of #![no_std].

Unfortunately I think this is not backwards compatible.

This would make it easier to write #![no_std] libraries that contain macros which will work regardless of if the consumer crate is no_std or not.

That's a good point, I've added a drawback to this RFC.

[eefriedman]

What's the point of stabilizing #![no_core]? It's not like it would actually be usable in stable Rust.

It makes zero sense to require users to provide an implementation of eh_personality. Assuming users don't do something weird, if you're not linking to libstd, there's no way to unwind, and therefore the eh_personality implementation will never be called. (Weird things here include manually calling _Unwind_RaiseException and unwinding through rust code by accident.)

A variant of the #[lang_items_abort] proposal: define an #[abort] attribute, as an alternative to all three lang-items. Say it has the signature fn abort(msg: &core::fmt::Arguments)->!, we call it whenever we hit any unrecoverable condition. It isn't allowed to unwind.

[eddyb]

@eefriedman libcore can panic (and thus unwind), that's why this weak lang item contraption exists in the first place.

[eefriedman]

@eddyb libcore can panic, sure, but without libstd's implementation of panic_fmt, it isn't possible to actually unwind.

[Ericson2314]

@eefriedman As a practical matter, I think rustc demands eh_personality to generate pads assuming panic_fmt is defined to unwind. But certainly I agree this is not an ideal situation, and a great reason why even the existence of eh_personality, not just its signature, shouldn't be stabilized.

@alexcrichton

I would personally like to enable this use case as having #![no_std] doesn't seem too useful without it

Again, I don't think instability around Rust in the kernel is a problem, now or in the foreseeable future. Stabilizing #![no_std] and the existence of core to solve a particular problem like the macros is different, but now it is less clear whether doing so would help with that.

[daboross]

#[no_std] makes sense as an attribute, it's fairly easy to tell what it's doing - #[no_core] however seems counterintuitive - it isn't exactly clear that it's also assuming #[no_std].

Would it make sense to just have one attribute, something like #[prelude()]? It would be used like #![prelude(core)] or #![prelude(none)], and #![prelude(std)] would be assumed if it isn't declared. believe it would make more sense to have using std, core, or no injected prelude all be under one attribute, rather than multiple.

[eddyb]

@daboross #![no_std] #[prelude] extern crate core; is actually what I expected the future direction to be.
Maybe we can still generalize prelude injection to custom and/or multiple crates.
That said, we also need to replace #[prelude_import]'s order-based glob priority with something proper, e.g. prelude glob imports can be overridden by glob imports which, in turn, can be overridden by explicit imports.

[Virtlink]

All crates (including libstd) should be treated equally. There should be nothing that libstd can do that any other crate can't.

Firstly, I'd agree with @eddyb: introduce #[prelude] to manually use the prelude of the marked crate. This removes the special treatment of libstd's prelude. And we don't want to treat libcore's prelude special either, so let's not do #![no_core] and instead require #[prelude] extern crate core for users that want to use libcore and its prelude.

Then for at least eh_personality and stack_exhausted I'd add stub implementations that can be overridden by the user. Most users using #![no_std] don't need any special behavior here. However, overriding these stubs would be unstable, such that their signatures may change in the future. Libstd is just another crate overriding these stubs, and not special in that regard.

Finally, by default any Rust crate would implicitly include #[prelude] extern crate std; unless #![no_std] is specified. Then #![no_std] would mean no defaults instead of no libstd and prelude, which I think is more logical.

[alexcrichton]

@Virtlink

Firstly, I'd agree with @eddyb: introduce #[prelude] to manually use the prelude of the marked crate

The question about what to do with preludes is somewhat orthogonal to the #![no_std] story, there's a separate RFC for dealing with custom preludes.

let's not do #![no_core] and instead require #[prelude] extern crate core for users that want to use libcore and its prelude.

The problem with this is that Rust isn't very useful without extern crate core because of the lang items that it defines, and we ideally want the #![no_std] case to be just as ergonomic as the normal use case, and we wouldn't necessarily expect all users to write extern crate std;

[Ericson2314]

My first priority is not stabilizing those lang items, but I'd prefer @eddyb's end goal too. Treating all crates as equally as possible an admirable goal, and one #[prelude] extern cate core; is but a tiny decrease in ergonomics.

In fact if we had proper glob-import priority like @eddyb requests, we could just do something like:

extern crate core;
use core::prelude_v1::*;

Even simpler!

Edit: proper glob-import priority, and crate-wide imports for exactly that.