add summary of Rust All Hands

Author: japaric

newsletters/2018-03-29.md

@@ -10,8 +10,188 @@ If you want to mention something in [the next newsletter], make sure to leave a
 [Embedded WG]: https://github.com/rust-lang-nursery/embedded-wg
 
 ## Highlights
+## The embedded WG at Rust All Hands
+
+This week ~15 Rust teams / working groups met for the Rust All Hands event. Some members of the
+embedded WG were present and we had a chance to talk to the compiler, core and infra teams. These
+are the highlights of our talks:
+
+### Embedded Rust on stable
+
+We had previously identified 3 unstable features / issues that tie embedded development to the
+nightly channel in https://github.com/japaric/stable-embedded-rust . We talk to the other Rust teams
+about the possibility of addressing these issues in time for the 2018 edition release and the
+conclusion was that they thought that the timeline was possible. These are the 3 unstable features
+we are referring to:
+
+- ~Xargo~
+
+We'll ship a rust-std component (pre-compiled core+compiler-builtins) for the thumb* and msp430
+  targets. This removes the need for Xargo so people will be able to do, for example, `rustup target
+  add thumb7m-none-eabi; cargo build --target thumbv7m-none-eabi` to cross compile to ARM Cortex-M.
+
+Tracking issue: [rust-lang/rust#49382].
+
+[rust-lang/rust#49382]: https://github.com/rust-lang/rust/issues/49382
+
+- `compiler-builtins`
+
+`extern crate compiler_builtins` is unstable to directly use. The fix we have decided on is to
+inject that as part of the prelude you get from `#![no_std]`.
+
+So, today `#![no_std]` expands to something like this:
+
+``` rust
+#![no_std]
+extern crate core;
+```
+
+With our change the expansion will run like this:
+
+``` rust
+#![no_std]
+extern crate core;
+extern crate compiler_builtins; // but this doesn't #![feature(compiler_builtins_lib)]
+```
+
+In the future we might want to merge `compiler-builtins` into `core` but that requires more effort
+and can still be done if we do the `#![no_std]` prelude approach right now.
+
+Tracking issue: [rust-lang/rust#49380]
+
+[rust-lang/rust#49380]: https://github.com/rust-lang/rust/issues/49380
+
+- `panic_fmt`
+
+There's an accepted RFC (#2070) for a stable mechanism to select the behavior of `panic!` in
+`no_std` context, and there's a know issue where the arguments of `panic_fmt` are kept in the binary
+even when they are unused by the `panic_fmt` implementation (cf. [rust-lang/embedded-wg#41]).
+
+[rust-lang/embedded-wg#41]: https://github.com/rust-lang-nursery/embedded-wg/issues/41
+
+The main concern here was whether we'll be able to fix the binary size problem with the accepted
+design or if we'll need some new design. The compiler team thinks that this can be fixed with the
+existing design using MIR only rlibs but it's unlikely this will get fixed in time for the edition
+release. @nagisa will likely propose an alternate solution that involves having Cargo select the
+panic provider crate.
+
+### Non critical unstable features
+
+There are some other unstable features that although don't prevent you from doing embedded
+development they come up often when doing no-std development. We had a chat with people on the
+compiler team about them.
+
+- `const fn`
+
+This feature has been proposed for stabilization (cf. [rust-lang/rust#24111]).
+
+[rust-lang/rust#24111]: https://github.com/rust-lang/rust/issues/24111#issuecomment-376649804
+
+- `asm!`
+
+Background: Some assembly operations can be implemented as external assembly files that are then
+called into using FFI; other ops though do need to be inlined into the function from which they are
+called to prevent losing semantics. Using external assembly file can be done on the stable channel.
+The second type of operation requires the unstable `asm!` macro.
+
+The compiler team is not 100% sure on whether they want to stabilize inline assembly for the edition
+release. The embedded WG has proposed an alternative proposal: expose *some* assembly operations
+that need to be inlined as "Rust intrinsics" -- in a similar fashion to how SIMD is being
+implemented; these intrinsics would be in the `core::asm::$ARCH` module and they could either be
+implemented by lowering to a LLVM intrinsics or using inline assembly. For example:
+
+``` rust
+pub mod asm {
+    pub mod arm {
+        #[inline(always)]
+        pub fn cpsid() {
+            unsafe {
+                asm!("cpsid i" ::: "memory" : "volatile");
+            }
+        }
+    }
+}
+```
+
+These would be stable APIs with an unstable implementation. If LLVM assembler syntax the
+implementations of these functions would have to be updated.
+
+The embedded WG will submit an RFC proposing the `asm` module and that will include a list of
+assembly operations that (a) are common and (b) need to be inlined for different architectures.
+
+- `#[used]`
+
+This experimental feature has been in the compiler for a while and it's required in some scenarios
+when using LTO to prevent the compiler some function / `static` that needs to be in the final
+binary.
+
+We'll try to get it stabilized by the edition release but it's not a high priority feature.
+
+### Stability of the embedded targets
+
+We don't only want to make embedded Rust possible on stable; we also want to make sure the embedded
+targets don't regress. So we are going to add tests to rust-lang/rust CI to make sure regression
+block PRs from landing.
+
+That effectively will make some of the embedded targets into the tier 1 platform. The core team is
+fine with adding the thumb* targets (ARM Cortex-M) to tier 1; less maintained, still in
+development and not fully mature targets like AVR, MSP430 and RISCV will become tier 3 -- they'll be
+tested but won't block PRs and rust-std binaries will be produced but it's not guaranteed there will
+be binaries available for all nightly / beta / stable releases.
+
+We'll open an issue to discuss with the infra team the exact tests we want to add and track progress
+on that, but have already told them about the kind of tests we want to add and they thought those
+kind of tests are possible to implement. The kind of tests we discussed were:
+
+- It compiles and links
+- Runs the cross compiled binary in QEMU doesn't crash and exits with exit code 0.
+- Tracking the binary size of a program compiled with `-Os` / `-Oz` and notify someone or fail the
+  build if the size regresses by 5% / 10% or something.
+
+### LLVM backends that are not yet in rustc
+
+There are two embedded LLVM backends that have not yet been enabled in rustc for different reasons:
+AVR and RISCV.
+
+In the case of AVR the main reason is that some LLVM codegen bugs prevent you from building core for
+AVR. These bugs are related to 128-bit integers and formatting floats. The libs team discussed this
+some time ago and they decided they are fine with landing arch specific `#[cfg]` attributes to
+remove 128-bit integers and other things like float APIs.
+
+In the case of RISCV the LLVM backend is currently under active development and our current version
+of LLVM doesn't fully support RISCV. We would have to backport several patches to make RISCV work on
+our LLVM version. The core team feels OK with backporting those patches as long as they have already
+landed in upstream LLVM, and are not still under review.
+
+### Tooling
+
+Getting tooling for e.g. binary inspection (e.g. `objdump`) can be hard on some platforms (e.g.
+Windows) specially for architecture which currently are not too widely used (e.g. RISCV). We can
+improve the situation here by shipping llvm tools with the Rust toolchain -- with one set of those
+tools you can inspect all the architectures that Rust supports. These are the thoughts of the core /
+infra team regarding this:
+
+- We put these tools in the sysroot and have them always shipped with the Rust toolchain so no
+  `rustup component add` required -- this is already the case with `lld`. It might not be possible
+  to provide these tools on all platforms but it's very likely they'll be available on tier 1
+  platforms.
+
+- We do *not* add these tools to the user `$PATH`. Instead some Cargo subcommand will be created by
+  the embedded WG (e.g. `cargo objdump`) and that subcommand will look for `llvm-objdump` in the
+  sysroot and do the right thing.
+
+- We make no guarantees about the semantics and interface of these tools being preserved over time
+  (e.g. CLI changes, user facing output format changes, etc.).
+
+### The embedded Rust book
+
+We decided on an initial audience for the embedded book; we will be targeting people that know some
+embedded stuff *and* some Rust. The main reason for this is that if someone knows one and not the
+other then they can go and read existing Rust documentation or the Discovery book and then read the
+embedded book. For more details check [rust-lang-nursery/embedded-wg#56].
+
+[rust-lang-nursery/embedded-wg#56]: https://github.com/rust-lang-nursery/embedded-wg/issues/56
 
-> TODO: More specific stuff from Rust All Hands?
 
 * [japaric], [hannobraun], and [jamesmunns] from the [Embedded WG] attended the 2018 Rust All Hands in Berlin, working on our goal to make [stable embedded rust development] possible in 2018!
 * [drbgn] has kicked off an investigation on how to [mock embedded-hal] to make testing sensors easier