I had multiple reports in #gv on (private) Mozilla slack complaining that building mobile/android (for GeckoView) was failing with: Compiling goblin v0.0.17 error[E0554]: #![feature] may not be used on the stable release channel --> third_party/rust/goblin/src/lib.rs:82:59 | 82 | #![cfg_attr(all(feature = "alloc", not(feature = "std")), feature(alloc))] These were fixed by `rustup default nightly`. I don't have the exact version of Rust stable that folks were complaining about, but locally I have: $ rustup run stable rustc --version rustc 1.28.0 (9634041f0 2018-07-30) $ rustup run nightly rustc --version rustc 1.30.0-nightly (6e0f1cc15 2018-09-05) That seems reasonable, since beta is 1.29.0. Maybe we really require beta (not nightly) and that isn't well communicated? :ted.mielczarek suggests that this is fallout from https://bugzilla.mozilla.org/show_bug.cgi?id=1457481, although I'll leave it to him to set the dependency fields.

As a short-term workaround, you should be able to use `ac_add_options --enable-rust-simd`. The issue here is that bug 1457481 added a dependency on the Rust object/goblin crates for Android, and is using `default-features = false`: https://hg.mozilla.org/mozilla-central/file/7566a6bac33d/tools/profiler/rust-helper/Cargo.toml#l8 I believe the right fix is to make that crate's `parse_elf` feature require the `std` feature in object here: https://hg.mozilla.org/mozilla-central/file/7566a6bac33d/tools/profiler/rust-helper/Cargo.toml#l15 More detailed explanation: object also uses `default-features = false` for goblin but enables most of its features: https://hg.mozilla.org/mozilla-central/file/255e04ebe3bd/third_party/rust/object/Cargo.toml#l28 except `std` which is forwarded from object's `std` feature (which rust-helper disables, per above): https://hg.mozilla.org/mozilla-central/file/255e04ebe3bd/third_party/rust/object/Cargo.toml#l48 ...and if you disable the `std` and `alloc` features in goblin, it asks rustc for the `alloc` feature: https://hg.mozilla.org/mozilla-central/file/255e04ebe3bd/third_party/rust/goblin/src/lib.rs#l81 `#![feature(...)` is not allowed on stable, so `#![feature(alloc)` breaks. (The `alloc` crate is not quite stable: https://github.com/rust-lang/rfcs/pull/2480 .) This doesn't break in CI because all of our CI builds use `--enable-rust-simd`: https://dxr.mozilla.org/mozilla-central/rev/17c314f6930d2b8d6e456aa9e9d41407a45c3008/build/mozconfig.rust#12 ...and that intentionally uses `RUSTC_BOOTSTRAP=1` to unlock unstable Rust features: https://dxr.mozilla.org/mozilla-central/rev/17c314f6930d2b8d6e456aa9e9d41407a45c3008/config/rules.mk#910

How is this building on automation if we're using stable rust there?

Per comment 1, all of our CI builds use `--enable-rust-simd`.

Thanks for the investigation, Ted! I'm taking a look at this now.

I filed bug 1496199 on standing up an Android build that would have caught this, since we already have builds like that for desktop Firefox.

Pushed by mstange@themasta.com: https://hg.mozilla.org/integration/autoland/rev/275985ae0d13 Enable std feature for object crate. r=mstange

(In reply to Ted Mielczarek [:ted] [:ted.mielczarek] from comment #1) > ...and that intentionally uses `RUSTC_BOOTSTRAP=1` to unlock unstable Rust > features: > https://dxr.mozilla.org/mozilla-central/rev/ > 17c314f6930d2b8d6e456aa9e9d41407a45c3008/config/rules.mk#910 And this is why RUSTC_BOOTSTRAP being set too broadly is hurting.