Orlando Oxidation 2018

Metadata

Oxidation meeting, Orlando All Hands
8.30am, Friday, Dec 7, 2018
Oxidation wiki: https://wiki.mozilla.org/Oxidation
Notes from the previous meeting: https://github.com/servo/servo/wiki/San-Francisco-Oxidation
Etherpad used for this meeting: https://public.etherpad-mozilla.org/p/oxi-orlando-2018
Chair: ted
Minutes: njn (plus attendees)

mw: incremental + thinLTO
- helps if you are benchmarking an optimized build
- needs more perf validation
- njn will do some comparisons
njn: NLL didn't regress things much
lld not default on Linux or Mac when compiling Firefox, is the default on Windows
- important because linking time is very high on some cases
- on Mac, dsymutil is expensive, option to disable it
- explicit output when linking/dsymutil'ing is happening might be useful
  - rust backtraces don't have info when dsymutil isn't run
  - we don't use backtraces for Firefox? could disable, but probably wouldn't save much time

mw: tested with Firefox, seems to work
compile times very high; probably higher than doing LTO on both sides
avoids need for some duplicated stylo functions, perf seems equivalent
requires same clang version for C++ and Rust (currently LLVM 8), otherwise crashes occur
- adds a potential constraint to the Firefox tool chain
- need to figure out if we pick particular versions of clang, etc.
- Rust has never had a real policy about when to update LLVM
- supporting many LLVM versions is a challenge for debugging work
next steps: make it a stable option, support better in Firefox build system
then can get rid of some code duplication

we can now edit vendored crates in mozilla-central and push to try
just add a patch section to cargo.toml
needs a mach command: https://bugzilla.mozilla.org/show_bug.cgi?id=1469248
need a good way to locally disable the --frozen flag in Cargo for experimentation/dev
- ted filed a Cargo issue ( https://github.com/rust-lang/cargo/issues/3066 )

chmanchester: should we re-evaluate our rustc update cadence, make it slower?
still need to keep up with Servo?
manish: webrender benefiting from rustc bug fixes, not sure if these are blockers, though
Firefox build system could be smarter, run rustup for you if it's present
sometimes have problems when updating rustc, e.g. compile time regressions, debuginfo issues
- we should run Firefox trunk against rustc nightly regularly to catch these problems early (possibly latest LLVM, too)
- servo has a Travis job that runs once a day and emails if there are problems

From Gankro (not in meeting): how can cbindgen/rust-bindgen better serve FF's needs?
the way cbindgen fails is bad: error messages are unhelpful, you have to run a follow-up command to get useful info
ajones: general issue of cross-language ergonomics
emilio is moving generic Firefox/rust glue stuff out of Stylo into a more general place so other crates can use it
ajones: is rust-bindgen/cbindgen the right solution?
ted: lessons to learn from wasm-bindgen? It seems to work very well
- acrichto: WebIDL gives a lot of structure and info about safety; wasm+JS are smaller than C++
manish: XPIDL! or only do cbindgen, and write all bindings in Rust?!? (i.e. Rust is the IDL)
ajones: mostly we're calling Rust from C++
ajones: process boundary == language boundary? manish: perf could be affected
ajones: how to improve things for small pieces of Rust code in Firefox?
ted: we are now at 6% Rust in Firefox (includes vendored crates that get into the build)

How to avoid node.js-style security problems?
Alex_Gaynor (not in meeting): Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1509971 about running cargo-audit regularly. As of the other day, we're cargo-audit clean on m-c.
Vendoring helps a bit -- all new code goes in via a patch, not just pulling from crates.io blindly
Google/Facebook face the same problems, nobody has silver bullets