Survey: unstable features you routinely (have to) use

[japaric]

This goal of this survey is to get an idea of what (currently) unstable Rust features would need to be stabilized to make embedded development feasible on the stable channel.

One unstable feature per comment. If an unstable feature you use is already listed in the comments up vote it (:+1: reaction) so we can track the number of users that feature has.

[japaric]

Xargo

Yup, Xargo only works with the nightly / dev channel because compiling the core crate requires a bunch of unstable features; some of them will probably never become stable.

[japaric]

#[lang_item = "panic_fmt"] (#![feature(lang_items)])

Required to build no_std Rust binaries. If you are building a binary crate that contains #![no_std] then something in you dependency graph is providing this.

[japaric]

extern crate compiler_builtins (#![feature(compiler_builtins)])

Provides softwae implementation of operations that don't directly map to hardware like floating point operations on the Cortex-M3 or 64-bit mulitplication on 32-bit architectures. If you have something like this:

[dependencies.compiler_builtins]
features = ["mem"]
git = "https://github.com/rust-lang-nursery/compiler-builtins"
stage = 1

in your Xargo.toml file then you are indirectly using this feature.

[japaric]

asm!() (#![feature(asm)])

If you are using the API in cortex_m::asm then you are indirectly using this feature.

[japaric]

#[linkage = "weak"] (#![feature(linkage)])

[japaric]

#[naked] (#![feature(naked_functions)])

[japaric]

#[used] (#![feature(used)])

[japaric]

const fn foo() (#![feature(const_fn)])

[japaric]

core::intrinsics (#![feature(core_intrinsics)])

[japaric]

global_asm!() (#![feature(global_asm)])

[coder543]

(note that this is just my opinion, maybe others disagree)

Just being able to build even the tiniest, most incomplete functional firmware in Rust completely using the stable toolchain is the first step. Anything else is secondary, but a lot of those secondary items are important. Specifically, that primarily means lang_items, I think. For practical embedded usage, the standard asm! macro is the very next thing on the list.

Everything on this informal survey is definitely useful to embedded developers. However, as an example, stabilizing weak linkage will not get anyone closer to compiling a minimal embedded example with the stable toolchain if lang_item is not available, so I feel like the very most important stuff on this list is already a known factor.

[japaric]

@coder543 I agree with everything you said. We, embedded developers, know what's required for "being able to build even the tiniest, most incomplete functional firmware in Rust completely using the stable toolchain" and what's "the very next thing on the list" but the Rust team doesn't -- they are not embedded developers. That's where this survey can help. I can tell (and I already have) the Rust team that the number one blocker for stable no-std application development is the panic_fmt lang item, but if I add "and 100% of N developers agree" to the message then that adds a sense of urgency.

[japaric]

PSA: rust-lang/rfcs#2070 proposes a stable mechanism to specify the behavior of panic! in no-std context; this mechanism would supersede the unstable panic_fmt lang item.

cc @adamgreig @therealprof @coder543 @pftbest @parched @Michael-F-Bryan @lexxvir @cmerrill

[jamesmunns]

I think we met most of these goals, or have opened follow on issues for most items listed here. Nominating this to be closed.

[jamesmunns]

I am closing this issue, please feel free to open another issue if you would like this discussed further.