From 2c32edae9fc10914f8483a059863c297a105e0de Mon Sep 17 00:00:00 2001 From: Alex Crichton Date: Sat, 27 Jun 2015 22:54:39 -0700 Subject: [PATCH 1/6] RFC: Stabilize the #![no_std] attribute 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. --- text/0000-stabilize-no_std.md | 267 ++++++++++++++++++++++++++++++++++ 1 file changed, 267 insertions(+) create mode 100644 text/0000-stabilize-no_std.md diff --git a/text/0000-stabilize-no_std.md b/text/0000-stabilize-no_std.md new file mode 100644 index 00000000000..80aea6ac0fa --- /dev/null +++ b/text/0000-stabilize-no_std.md @@ -0,0 +1,267 @@ +- Feature Name: N/A +- Start Date: 2015-06-26 +- RFC PR: (leave this empty) +- Rust Issue: (leave this empty) + +# Summary + +Stabilize the `#![no_std]` attribute, add a new `#![no_core]` attribute, and +start stabilizing the libcore library. + +# Motivation + +Currently all stable Rust programs must link to the standard library (libstd), +and it is impossible to opt out of this. The standard library is not appropriate +for use cases such as kernels, embedded development, or some various niche cases +in userspace. For these applications Rust itself is appropriate, but the +compiler does not provide a stable interface compiling in this mode. + +The standard distribution provides a library, libcore, which is "the essence of +Rust" as it provides many language features such as iterators, slice methods, +string methods, etc. The defining feature of libcore is that it has 0 +dependencies, unlike the standard library which depends on many I/O APIs, for +example. The purpose of this RFC is to provide a stable method to access +libcore. + +Applications which do not want to use libstd still want to use libcore 99% of +the time, but unfortunately the current `#![no_std]` attribute does not do a +great job in facilitating this. When moving into the realm of not using the +standard library, the compiler should make the use case as ergonomic as +possible, so this RFC proposes different behavior than today's `#![no_std]`. + +Finally, the standard library defines a number of language items which must be +defined when libstd is not used. These language items are: + +* `panic_fmt` +* `eh_personality` +* `stack_exhausted` + +To be able to usefully leverage `#![no_std]` in stable Rust these lang items +must be available in a stable fashion. + +# Detailed Design + +This RFC proposes a nuber of changes: + +* Stabilize the `#![no_std]` attribute after tweaking its behavior slightly +* Stabilize a `#![no_core]` attribute. +* Stabilize the name "core" in libcore. +* Stabilize required language items by the core library. + +## `no_std` + +The `#![no_std]` attribute currently provides two pieces of functionality: + +* The compiler no longer injects `extern crate std` at the top of a crate. +* The prelude (`use std::prelude::v1::*`) is no longer injected at the top of + every module. + +This RFC proposes adding the following behavior to the `#![no_std]` attribute: + +* The compiler will inject `extern crate core` at the top of a crate. +* The libcore prelude will be injected at the top of every module. + +Most uses of `#![no_std]` already want behavior along these lines as they want +to use libcore, just not the standard library. + +## `no_core` + +A new attribute will be added to the compiler, `#![no_core]`, which serves two +purposes: + +* This attribute implies the `#![no_std]` attribute (no std prelude/crate + injection). +* This attribute will prevent core prelude/crate injection. + +Users of `#![no_std]` today who do *not* use libcore would migrate to moving +this attribute instead of `#![no_std]`. + +## Stabilization of libcore + +This RFC does not yet propose a stabilization path for the contents of libcore, +but it proposes stabilizing the name `core` for libcore, paving the way for the +rest of the library to be stabilized. The exact method of stabilizing its +contents will be determined with a future RFC or pull requests. + +## Stabilizing lang items + +This section will describe the purpose for each lang item currently required in +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. + +Like lang items each of these will only allow one implementor in any crate +dependency graph which will be verified at compile time. Also like today, none +of these lang items will be required unless a static library, dynamic library, +or executable is being produced. In other words, libraries (rlibs) do not need +(and probably should not) to define these items. + +#### `panic_fmt` + +This lang item is the definition of how to panic in Rust. The standard library +defines this by throwing an exception (in a platform-specific manner), but users +of libcore often want to define their own meaning of panicking. The signature of +this function will be: + +```rust +#[panic_fmt] +pub extern fn panic_fmt(msg: &core::fmt::Arguments) -> !; +``` + +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 +file/line number information in panics (as it does today) by assembling a new +`core::fmt::Arguments` value which uses the old one and appends the file/line +information. + +This signature also differs from today's implementation by taking a `&Arguments` +instead of taking it by value, and the purpose of this is to ensure that the +function has a clearly defined ABI on all platforms in case that is required. + +#### `eh_personality` + +The compiler will continue to compile libcore with landing pads (e.g. cleanup to +run on panics), and a "personality function" is required by LLVM to be available +to call for each landing pad. In the current implementation of panicking, a +personality function is typically just calling a standard personality function +in libgcc (or in MSVC's CRT), but the purpose is to indicate whether an +exception should be caught or whether cleanup should be run for this particular +landing pad and exception combination. + +The exact signature of this function is quite platform-specific, but many users +of libcore will never actually call this function as exceptions will not be +thrown (many will likely compile with `-Z no-landing-pads` anyway). As a result +the signature of this lang item will not be defined, but instead it will simply +be required to be defined (as libcore will reference the symbol name +regardless). + +```rust +#[eh_personality] +pub extern fn eh_personality(...) -> ...; +``` + +The compiler will not check the signature of this function, but it will assign +it a known symbol so libcore can be successfully linked. + +#### `stack_exhausted` + +The current implementation of stack overflow in the compiler is to use LLVM's +segmented stack support, inserting a prologue to every function in an object +file to detect when a stack overflow occurred. When a stack overflow is +detected, LLVM emits code that will call the symbol `__morestack`, which the +Rust distribution provides an implementation of. Our implementation, however, +then in turn calls a this `stack_exhausted` language item to define the +implementation of what happens on stack overflow. + +The compiler therefore needs to ensure that this lang item is present in order +for libcore to be correctly linked, so the lang item will have the following +signature: + +```rust +#[stack_exhausted] +pub extern fn stack_exhausted() -> !; +``` + +The compiler will control the symbol name and visibility of this function. + +# Drawbacks + +The current distribution provides precisely one library, the standard library, +for general consumption of Rust programs. Adding a new one (libcore) is adding +more surface area to the distribution (in addition to adding a new `#![no_core]` +attribute). This surface area is greatly desired, however. + +When using `#![no_std]` the experience of Rust programs isn't always the best as +there are some pitfalls that can be run into easily. For example, macros and +plugins sometimes hardcode `::std` paths, but most ones in the standard +distribution have been updated to use `::core` in the case that `#![no_std]` is +present. Another example is that common utilities like vectors, pointers, and +owned strings are not available without liballoc, which will remain an unstable +library. This means that users of `#![no_std]` will have to reimplement all of +this functionality themselves. + +This RFC does not yet pave a way forward for using `#![no_std]` and producing an +executable because the `#[start]` item is required, but remains feature gated. +This RFC just enables creation of Rust static or dynamic libraries which don't +depend on the standard library in addition to Rust libraries (rlibs) which do +not depend on the standard library. + +On the topic of lang item stabilization, it's likely expected that the +`panic_fmt` lang item must be defined, but the other two, `eh_personality` and +`stack_exhausted` are generally quite surprising. Code using `#![no_std]` is +also likely to very rarely actually make use of these functions: + +* Most no-std contexts don't throw exceptions (or don't have exceptions), so + they either have stubs that panic or just compile with `-Z no-landing-pads`, + so the `eh_personality` may not strictly be necessary to be defined in order + to link against libcore. +* Additionally, most no-std contexts don't actually set up stack overflow + detection, so the `stack_exhausted` function will either never be compiled or + the crates are compiled with `-C no-stack-check` meaning that the item may not + strictly be necessary to be defined. + +Currently, however, a binary distribution of libcore is provided which is +compiled with unwinding and stack overflow checks enabled. Consequently the +libcore library does indeed depend on these two symbols and require these items +to be defined. It is seen as not-that-large of a drawback for the following +reasons: + +* The functions `eh_personality` and `stack_exhausted` are fairly easy to + define, and are only required by end products (not Rust libraries). +* It's easy for the compiler to *stop* requiring these functions to be defined + in the future if we, for example, provide multiple binary copies of libcore in + the standard distribution. + +The final drawback of this RFC is the overall stabilization of the `#![no_std]` +attribute, meaning that the compiler will no longer be able to make assumptions +in the future about a function being defined. Put another way, the `panic_fmt`, +`eh_personality`, and `stack_exhausted` lang items are the only three that will +ever be able to be required to be defined by downstream crates. This is not seen +as too strong of a drawback as it's not clear that the compiler will need to +assume more functions exist. Additionally, the compiler will likely be able to +provide or emit a stub implementation for any future symbol it does need to +exist. + +# Alternatives + +Most of the strategies taken in this RFC have some minor variations on what can +happen: + +* The `#![no_std]` attribute could be stabilized as-is without adding a + `#![no_core]` attribute, requiring users to write `extern crate core` and + import the core prelude manually. The burden of adding `#![no_core]` to the + compiler, however, is seen as not-too-bad compared to the increase in + ergonomics of using `#![no_std]`. +* The language items could continue to use the same `#[lang = "..."]` syntax and + we could just stabilize a subset of the `#[lang]` items. It seems more + consistent, however, to blanket feature-gate all `#[lang]` attributes instead + of allowing three particular ones, so individual attributes are proposed. +* The `panic_fmt` lang item could retain the same signature today, but it has an + unclear ABI (passing `Arguments` by value) and we may not want to 100% commit + to always passing filename/line information on panics. +* The `eh_personality` and `stack_exhausted` lang items could not be required to + be defined, and the compiler could provide aborting stubs to be linked in if + they aren't defined anywhere else. +* The compiler could not require `eh_personality` or `stack_exhausted` if no + crate in the dependency tree has landing pads enabled or stack overflow checks + enabled. This is quite a difficult situation to get into today, however, as + the libcore distribution always has these enabled and Cargo does not easily + provide a method to configure this when compiling crates. The overhead of + defining these functions seems small and because the compiler could stop + requiring them in the future it seems plausibly ok to require them today. +* A `#[lang_items_abort]` attribute could be added to explicitly define the the + `eh_personality` and `stack_exhausted` lang items to immediately abort. This + would avoid us having to stabilize their signatures as we could stabilize just + this attribute and not their definitions. + +# Unresolved Questions + +* How important/common are `#![no_std]` executables? Should this RFC attempt to + stabilize that as well? +* When a staticlib is emitted should the compiler *guarantee* that a + `#![no_std]` one will link by default? This precludes us from ever adding + future require language items for features like unwinding or stack exhaustion + by default. For example if a new security feature is added to LLVM and we'd + like to enable it by default, it may require that a symbol or two is defined + somewhere in the compilation. From 0d8fcae61e7cbefef6818a6a0173870490befde6 Mon Sep 17 00:00:00 2001 From: Alex Crichton Date: Wed, 1 Jul 2015 10:44:17 -0700 Subject: [PATCH 2/6] Mention not stabilizing lang items as an alternative. --- text/0000-stabilize-no_std.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/text/0000-stabilize-no_std.md b/text/0000-stabilize-no_std.md index 80aea6ac0fa..d577ff240e7 100644 --- a/text/0000-stabilize-no_std.md +++ b/text/0000-stabilize-no_std.md @@ -254,6 +254,9 @@ happen: `eh_personality` and `stack_exhausted` lang items to immediately abort. This would avoid us having to stabilize their signatures as we could stabilize just this attribute and not their definitions. +* The various language items could not be stabilized at this time, allowing + stable libraries that leverage `#![no_std]` but not stable final artifacts + (e.g. staticlibs, dylibs, or binaries). # Unresolved Questions From dc1d2cf443e1f7d0ac20b616db5c5a880a55e6ee Mon Sep 17 00:00:00 2001 From: Alex Crichton Date: Wed, 1 Jul 2015 10:50:56 -0700 Subject: [PATCH 3/6] Add downside of #![no_std] and std interoperation --- text/0000-stabilize-no_std.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/text/0000-stabilize-no_std.md b/text/0000-stabilize-no_std.md index d577ff240e7..fc8ecad2a0e 100644 --- a/text/0000-stabilize-no_std.md +++ b/text/0000-stabilize-no_std.md @@ -89,7 +89,9 @@ This section will describe the purpose for each lang item currently required in 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. +identify an implementation. It should be noted that these language items are +already not quite the same as other `#[lang]` items due to the ability to rely +on them in a "weak" fashion. Like lang items each of these will only allow one implementor in any crate dependency graph which will be verified at compile time. Also like today, none @@ -213,7 +215,7 @@ reasons: in the future if we, for example, provide multiple binary copies of libcore in the standard distribution. -The final drawback of this RFC is the overall stabilization of the `#![no_std]` +Another drawback of this RFC is the overall stabilization of the `#![no_std]` attribute, meaning that the compiler will no longer be able to make assumptions in the future about a function being defined. Put another way, the `panic_fmt`, `eh_personality`, and `stack_exhausted` lang items are the only three that will @@ -223,6 +225,13 @@ assume more functions exist. Additionally, the compiler will likely be able to provide or emit a stub implementation for any future symbol it does need to exist. +In stabilizing the `#![no_std]` attribute it's likely that a whole ecosystem of +crates will arise which work with `#![no_std]`, but in theory all of these +crates should also interoperate with the rest of the ecosystem using `std`. +Unfortunately, however, there are known cases where this is not possible. For +example if a macro is exported from a `#![no_std]` crate which references items +from `core` it won't work by default with a `std` library. + # Alternatives Most of the strategies taken in this RFC have some minor variations on what can From aba213dae631b84560857b7358faeedbac018f35 Mon Sep 17 00:00:00 2001 From: Alex Crichton Date: Thu, 2 Jul 2015 16:47:06 -0700 Subject: [PATCH 4/6] Introduce no_core, don't stabilize it --- text/0000-stabilize-no_std.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-stabilize-no_std.md b/text/0000-stabilize-no_std.md index fc8ecad2a0e..3eb8125aaf8 100644 --- a/text/0000-stabilize-no_std.md +++ b/text/0000-stabilize-no_std.md @@ -44,7 +44,7 @@ must be available in a stable fashion. This RFC proposes a nuber of changes: * Stabilize the `#![no_std]` attribute after tweaking its behavior slightly -* Stabilize a `#![no_core]` attribute. +* Introduce a `#![no_core]` attribute. * Stabilize the name "core" in libcore. * Stabilize required language items by the core library. From d56f29dd3cf0b2c7ecbfa9ed581dab5cd5a4cc2d Mon Sep 17 00:00:00 2001 From: Alex Crichton Date: Wed, 8 Jul 2015 16:05:00 -0700 Subject: [PATCH 5/6] Recommend #![lang_items_abort] instead. --- text/0000-stabilize-no_std.md | 178 +++++++++------------------------- 1 file changed, 47 insertions(+), 131 deletions(-) diff --git a/text/0000-stabilize-no_std.md b/text/0000-stabilize-no_std.md index 3eb8125aaf8..aa18fa09775 100644 --- a/text/0000-stabilize-no_std.md +++ b/text/0000-stabilize-no_std.md @@ -46,7 +46,7 @@ This RFC proposes a nuber of changes: * Stabilize the `#![no_std]` attribute after tweaking its behavior slightly * Introduce a `#![no_core]` attribute. * Stabilize the name "core" in libcore. -* Stabilize required language items by the core library. +* Introduce a `#![lang_items_abort]` attribute. ## `no_std` @@ -85,87 +85,35 @@ contents will be determined with a future RFC or pull requests. ## Stabilizing lang items -This section will describe the purpose for each lang item currently required in -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. It should be noted that these language items are -already not quite the same as other `#[lang]` items due to the ability to rely -on them in a "weak" fashion. - -Like lang items each of these will only allow one implementor in any crate -dependency graph which will be verified at compile time. Also like today, none -of these lang items will be required unless a static library, dynamic library, -or executable is being produced. In other words, libraries (rlibs) do not need -(and probably should not) to define these items. - -#### `panic_fmt` - -This lang item is the definition of how to panic in Rust. The standard library -defines this by throwing an exception (in a platform-specific manner), but users -of libcore often want to define their own meaning of panicking. The signature of -this function will be: - -```rust -#[panic_fmt] -pub extern fn panic_fmt(msg: &core::fmt::Arguments) -> !; -``` - -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 -file/line number information in panics (as it does today) by assembling a new -`core::fmt::Arguments` value which uses the old one and appends the file/line -information. - -This signature also differs from today's implementation by taking a `&Arguments` -instead of taking it by value, and the purpose of this is to ensure that the -function has a clearly defined ABI on all platforms in case that is required. - -#### `eh_personality` - -The compiler will continue to compile libcore with landing pads (e.g. cleanup to -run on panics), and a "personality function" is required by LLVM to be available -to call for each landing pad. In the current implementation of panicking, a -personality function is typically just calling a standard personality function -in libgcc (or in MSVC's CRT), but the purpose is to indicate whether an -exception should be caught or whether cleanup should be run for this particular -landing pad and exception combination. - -The exact signature of this function is quite platform-specific, but many users -of libcore will never actually call this function as exceptions will not be -thrown (many will likely compile with `-Z no-landing-pads` anyway). As a result -the signature of this lang item will not be defined, but instead it will simply -be required to be defined (as libcore will reference the symbol name -regardless). - -```rust -#[eh_personality] -pub extern fn eh_personality(...) -> ...; -``` - -The compiler will not check the signature of this function, but it will assign -it a known symbol so libcore can be successfully linked. - -#### `stack_exhausted` - -The current implementation of stack overflow in the compiler is to use LLVM's -segmented stack support, inserting a prologue to every function in an object -file to detect when a stack overflow occurred. When a stack overflow is -detected, LLVM emits code that will call the symbol `__morestack`, which the -Rust distribution provides an implementation of. Our implementation, however, -then in turn calls a this `stack_exhausted` language item to define the -implementation of what happens on stack overflow. - -The compiler therefore needs to ensure that this lang item is present in order -for libcore to be correctly linked, so the lang item will have the following -signature: - -```rust -#[stack_exhausted] -pub extern fn stack_exhausted() -> !; -``` - -The compiler will control the symbol name and visibility of this function. +As mentioned above, there are three separate lang items which are required by +the libcore library to link correctly. These items are: + +* `panic_fmt` +* `stack_exhausted` +* `eh_personality` + +This RFC does **not** attempt to stabilize these lang items for a number of +reasons: + +* The exact set of these lang items is somewhat nebulous and may change over + time. +* The signatures of each of these lang items can either be platform-specific or + it's just "too weird" to stabilize. +* These items are pretty obscure and it's not very widely known what they do or + how they should be implemented. + +For `#![no_std]` to be generally useful, however, these lang items *must* be +able to be defined in one form or another on stable Rust, so this RFC proposes a +new crate attribute, `lang_items_abort`, which will define these functions. Any +crate tagged with `#![lang_items_abort]` will cause the compiler to generate any +necessary language items to get the program to correctly link. Each lang item +generated will simply abort the program as if it called the `intrinsics::abort` +function. + +This attribute will behave the same as `#[lang]` in terms of uniqueness, two +crates declaring `#![lang_items_abort]` cannot be linked together and an +upstream crate declaring this attribute means that no downstream crate has to +worry about it. # Drawbacks @@ -189,41 +137,12 @@ This RFC just enables creation of Rust static or dynamic libraries which don't depend on the standard library in addition to Rust libraries (rlibs) which do not depend on the standard library. -On the topic of lang item stabilization, it's likely expected that the -`panic_fmt` lang item must be defined, but the other two, `eh_personality` and -`stack_exhausted` are generally quite surprising. Code using `#![no_std]` is -also likely to very rarely actually make use of these functions: - -* Most no-std contexts don't throw exceptions (or don't have exceptions), so - they either have stubs that panic or just compile with `-Z no-landing-pads`, - so the `eh_personality` may not strictly be necessary to be defined in order - to link against libcore. -* Additionally, most no-std contexts don't actually set up stack overflow - detection, so the `stack_exhausted` function will either never be compiled or - the crates are compiled with `-C no-stack-check` meaning that the item may not - strictly be necessary to be defined. - -Currently, however, a binary distribution of libcore is provided which is -compiled with unwinding and stack overflow checks enabled. Consequently the -libcore library does indeed depend on these two symbols and require these items -to be defined. It is seen as not-that-large of a drawback for the following -reasons: - -* The functions `eh_personality` and `stack_exhausted` are fairly easy to - define, and are only required by end products (not Rust libraries). -* It's easy for the compiler to *stop* requiring these functions to be defined - in the future if we, for example, provide multiple binary copies of libcore in - the standard distribution. - -Another drawback of this RFC is the overall stabilization of the `#![no_std]` -attribute, meaning that the compiler will no longer be able to make assumptions -in the future about a function being defined. Put another way, the `panic_fmt`, -`eh_personality`, and `stack_exhausted` lang items are the only three that will -ever be able to be required to be defined by downstream crates. This is not seen -as too strong of a drawback as it's not clear that the compiler will need to -assume more functions exist. Additionally, the compiler will likely be able to -provide or emit a stub implementation for any future symbol it does need to -exist. +On the topic of lang items, it's somewhat unfortunate that the implementation of +a panic cannot be defined on stable Rust. The `#![lang_items_abort]` attribute +unconditionally defines all lang items, including `panic_fmt`, so it's not +possible to provide a custom implementation of the `panic_fmt` lang item while +still asking the compiler to define others like `eh_personality` and +`stack_exhausted`. In stabilizing the `#![no_std]` attribute it's likely that a whole ecosystem of crates will arise which work with `#![no_std]`, but in theory all of these @@ -242,16 +161,10 @@ happen: import the core prelude manually. The burden of adding `#![no_core]` to the compiler, however, is seen as not-too-bad compared to the increase in ergonomics of using `#![no_std]`. -* The language items could continue to use the same `#[lang = "..."]` syntax and - we could just stabilize a subset of the `#[lang]` items. It seems more - consistent, however, to blanket feature-gate all `#[lang]` attributes instead - of allowing three particular ones, so individual attributes are proposed. -* The `panic_fmt` lang item could retain the same signature today, but it has an - unclear ABI (passing `Arguments` by value) and we may not want to 100% commit - to always passing filename/line information on panics. -* The `eh_personality` and `stack_exhausted` lang items could not be required to - be defined, and the compiler could provide aborting stubs to be linked in if - they aren't defined anywhere else. +* The lang items could not be required to be defined, and the compiler could + provide aborting stubs to be linked in if they aren't defined anywhere else. + This has the downside of perhaps silently aborting a program, however, without + an explicit opt-in. * The compiler could not require `eh_personality` or `stack_exhausted` if no crate in the dependency tree has landing pads enabled or stack overflow checks enabled. This is quite a difficult situation to get into today, however, as @@ -259,13 +172,16 @@ happen: provide a method to configure this when compiling crates. The overhead of defining these functions seems small and because the compiler could stop requiring them in the future it seems plausibly ok to require them today. -* A `#[lang_items_abort]` attribute could be added to explicitly define the the - `eh_personality` and `stack_exhausted` lang items to immediately abort. This - would avoid us having to stabilize their signatures as we could stabilize just - this attribute and not their definitions. +* The lang items could be stabilized at this time instead of providing a way to + have the compiler generate an appropriate function. The downsides of this + approach, however, were listed above. * The various language items could not be stabilized at this time, allowing stable libraries that leverage `#![no_std]` but not stable final artifacts (e.g. staticlibs, dylibs, or binaries). +* Another stable crate could be provided by the distribution which provides + definitions of these lang items which are all wired to abort. This has the + downside of selecting a name for this crate, however, and also inflating the + crates in our distribution again. # Unresolved Questions From c78deef0fa4de5492c8870ae4d18c3e9b5f7558c Mon Sep 17 00:00:00 2001 From: Alex Crichton Date: Wed, 29 Jul 2015 14:34:05 -0700 Subject: [PATCH 6/6] Remove all mentions of stabilizing lang items --- text/0000-stabilize-no_std.md | 53 ++++++----------------------------- 1 file changed, 9 insertions(+), 44 deletions(-) diff --git a/text/0000-stabilize-no_std.md b/text/0000-stabilize-no_std.md index aa18fa09775..9d8ee92e95d 100644 --- a/text/0000-stabilize-no_std.md +++ b/text/0000-stabilize-no_std.md @@ -5,8 +5,8 @@ # Summary -Stabilize the `#![no_std]` attribute, add a new `#![no_core]` attribute, and -start stabilizing the libcore library. +Tweak the `#![no_std]` attribute, add a new `#![no_core]` attribute, and +pave the way for stabilizing the libcore library. # Motivation @@ -43,10 +43,9 @@ must be available in a stable fashion. This RFC proposes a nuber of changes: -* Stabilize the `#![no_std]` attribute after tweaking its behavior slightly +* Tweak the `#![no_std]` attribute slightly. * Introduce a `#![no_core]` attribute. -* Stabilize the name "core" in libcore. -* Introduce a `#![lang_items_abort]` attribute. +* Pave the way to stabilize the `core` module. ## `no_std` @@ -79,9 +78,9 @@ this attribute instead of `#![no_std]`. ## Stabilization of libcore This RFC does not yet propose a stabilization path for the contents of libcore, -but it proposes stabilizing the name `core` for libcore, paving the way for the -rest of the library to be stabilized. The exact method of stabilizing its -contents will be determined with a future RFC or pull requests. +but it proposes readying to stabilize the name `core` for libcore, paving the +way for the rest of the library to be stabilized. The exact method of +stabilizing its contents will be determined with a future RFC or pull requests. ## Stabilizing lang items @@ -102,18 +101,8 @@ reasons: * These items are pretty obscure and it's not very widely known what they do or how they should be implemented. -For `#![no_std]` to be generally useful, however, these lang items *must* be -able to be defined in one form or another on stable Rust, so this RFC proposes a -new crate attribute, `lang_items_abort`, which will define these functions. Any -crate tagged with `#![lang_items_abort]` will cause the compiler to generate any -necessary language items to get the program to correctly link. Each lang item -generated will simply abort the program as if it called the `intrinsics::abort` -function. - -This attribute will behave the same as `#[lang]` in terms of uniqueness, two -crates declaring `#![lang_items_abort]` cannot be linked together and an -upstream crate declaring this attribute means that no downstream crate has to -worry about it. +Stabilization of these lang items (in any form) will be considered in a future +RFC. # Drawbacks @@ -137,13 +126,6 @@ This RFC just enables creation of Rust static or dynamic libraries which don't depend on the standard library in addition to Rust libraries (rlibs) which do not depend on the standard library. -On the topic of lang items, it's somewhat unfortunate that the implementation of -a panic cannot be defined on stable Rust. The `#![lang_items_abort]` attribute -unconditionally defines all lang items, including `panic_fmt`, so it's not -possible to provide a custom implementation of the `panic_fmt` lang item while -still asking the compiler to define others like `eh_personality` and -`stack_exhausted`. - In stabilizing the `#![no_std]` attribute it's likely that a whole ecosystem of crates will arise which work with `#![no_std]`, but in theory all of these crates should also interoperate with the rest of the ecosystem using `std`. @@ -161,23 +143,6 @@ happen: import the core prelude manually. The burden of adding `#![no_core]` to the compiler, however, is seen as not-too-bad compared to the increase in ergonomics of using `#![no_std]`. -* The lang items could not be required to be defined, and the compiler could - provide aborting stubs to be linked in if they aren't defined anywhere else. - This has the downside of perhaps silently aborting a program, however, without - an explicit opt-in. -* The compiler could not require `eh_personality` or `stack_exhausted` if no - crate in the dependency tree has landing pads enabled or stack overflow checks - enabled. This is quite a difficult situation to get into today, however, as - the libcore distribution always has these enabled and Cargo does not easily - provide a method to configure this when compiling crates. The overhead of - defining these functions seems small and because the compiler could stop - requiring them in the future it seems plausibly ok to require them today. -* The lang items could be stabilized at this time instead of providing a way to - have the compiler generate an appropriate function. The downsides of this - approach, however, were listed above. -* The various language items could not be stabilized at this time, allowing - stable libraries that leverage `#![no_std]` but not stable final artifacts - (e.g. staticlibs, dylibs, or binaries). * Another stable crate could be provided by the distribution which provides definitions of these lang items which are all wired to abort. This has the downside of selecting a name for this crate, however, and also inflating the