-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Stabilize the #![no_std] attribute #1184
Conversation
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. Finally, stabilize a number of language items required by libcore which the standard library defines.
addition to the interface that it will be stabilized with. Each lang item will | ||
no longer be defined with the `#[lang = "..."]` syntax but will instead receive | ||
a dedicated attribute (e.g. `#[panic_fmt]`) to be attached to functions to | ||
identify an implementation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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 |
I propose that |
``` | ||
|
||
This differs with the `panic_fmt` function today in that the file and line | ||
number arguments are omitted. The libcore library will continue to provide |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the rationale behind this change? This was convenient for formatting reasons, and I don't see why it should go.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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. |
I agree about not stabilizing any language items here, if this is just for allowing However - if stabilizing these language items will allow compilation of no_std binaries (using an externally defined entrypoint, instead of |
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. |
@Tobba I thought |
@eddyb As far as I know it only works for referencing the current crate. |
|
||
```rust | ||
#[panic_fmt] | ||
pub extern fn panic_fmt(msg: &core::fmt::Arguments) -> !; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
@Ericson2314, @Tobba, @thepowersgang
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
Unfortunately I think this is not backwards compatible.
That's a good point, I've added a drawback to this RFC. |
What's the point of stabilizing It makes zero sense to require users to provide an implementation of A variant of the |
@eefriedman libcore can panic (and thus unwind), that's why this weak lang item contraption exists in the first place. |
@eddyb libcore can panic, sure, but without libstd's implementation of panic_fmt, it isn't possible to actually unwind. |
@eefriedman As a practical matter, I think rustc demands
Again, I don't think instability around Rust in the kernel is a problem, now or in the foreseeable future. Stabilizing |
Would it make sense to just have one attribute, something like |
@daboross |
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 Then for at least Finally, by default any Rust crate would implicitly include |
The question about what to do with preludes is somewhat orthogonal to the
The problem with this is that Rust isn't very useful without |
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 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. |
As @alexcrichton already mentioned, there was subteam consensus to merge this after scaling it back slightly (as per discussion with @dschatzberg and others). |
This commit is an implementation of [RFC 1184][rfc] which tweaks the behavior of the `#![no_std]` attribute and adds a new `#![no_core]` attribute. The `#![no_std]` attribute now injects `extern crate core` at the top of the crate as well as the libcore prelude into all modules (in the same manner as the standard library's prelude). The `#![no_core]` attribute disables both std and core injection. [rfc]: rust-lang/rfcs#1184
This commit is an implementation of [RFC 1184][rfc] which tweaks the behavior of the `#![no_std]` attribute and adds a new `#![no_core]` attribute. The `#![no_std]` attribute now injects `extern crate core` at the top of the crate as well as the libcore prelude into all modules (in the same manner as the standard library's prelude). The `#![no_core]` attribute disables both std and core injection. [rfc]: rust-lang/rfcs#1184 Closes #27394
Broken on latest rust nightly because using no_std automatically injects an "extern crate core". (rust-lang/rfcs#1184)
Stabilize the
#![no_std]
attribute while also improving the ergonomics ofusing libcore by default. Additionally add a new
#![no_core]
attribute to optout of linking to libcore.
rendered