I noticed this was happening, and it matches my reading of the patch in bug 1300835. Is this intended behavior? What do we do for CFLAGS?
We generally try to persist CFLAGS/CXXFLAGS that you set in your mozconfig. We could do the same for RUSTFLAGS. You'll still hit some potential weirdness but it's no different from the CFLAGS case--if you set `CFLAGS=-O2` or `CFLAGS=-g3` or something like that the effect is not really predictable (because we set optimization flags and debug info flags elsewhere).
In general I think the Rust compiler tries to prioritize options at the end of the string over options at the beginning, so if we followed those semantics we should have mostly-predictable behavior. This would be nice so that people can manually pass the correct codegen-units, at least until  lands.  https://github.com/rust-lang/rust/issues/38276
This is needed to enable code coverage for Rust.
To implement this you'd just need two pieces: 1) A bit in moz.configure to take RUSTFLAGS from the environment as an option, something like: https://dxr.mozilla.org/mozilla-central/rev/8a3aa1701537ea6b8334f432cd030d260d492fa3/build/moz.configure/toolchain.configure#894 + a set_config('RUSTFLAGS', ...) 2) Pass $(RUSTFLAGS) in the rustflags_override variable which is what we use to pass RUSTFLAGS to cargo invocations currently: https://dxr.mozilla.org/mozilla-central/rev/8a3aa1701537ea6b8334f432cd030d260d492fa3/config/rules.mk#946
Created attachment 8874645 [details] [diff] [review] Patch
Assignee: nobody → mcastelluccio
Status: NEW → ASSIGNED
Attachment #8874645 - Flags: review?(ted)
Attachment #8874645 - Flags: review?(ted) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/06967108134b Allow setting additional rustflags via mozconfig. r=ted
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago
status-firefox55: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
You need to log in before you can comment on or make changes to this bug.