https://wiki.mozilla.org/api.php?action=feedcontributions&user=Nnethercote&feedformat=atomMozillaWiki - User contributions [en]2024-03-29T05:44:44ZUser contributionsMediaWiki 1.27.4https://wiki.mozilla.org/index.php?title=Modules/Core&diff=1232420Modules/Core2020-11-29T20:06:06Z<p>Nnethercote: </p>
<hr />
<div><noinclude><br />
'''Only module owners may edit this page.''' <br />
<br />
They may:<br />
<br />
* update any information about their module except the name of the owner<br />
* add or remove sub-modules<br />
* change the owner of a sub-module <br />
* add emeritus owners or peers<br />
<br />
Other changes, including changes of module owner or addition/removal of modules, must be agreed with the Module Ownership Module group, probably via a discussion in [https://www.mozilla.org/about/forums/#governance mozilla.governance].<br />
</noinclude><br />
{{Module<br />
|name=Accessibility<br />
|description=Support for platform accessibility APIs. Accessibility APIs are used by 3rd party software like screen readers, screen magnifiers, and voice dictation software, which need information about document content and UI controls, as well as important events like changes of focus.<br />
|owner=[mailto:jteh@mozilla.com Jamie Teh]<br />
|peers=[mailto:eitan@monotonous.org Eitan Isaacson], [mailto:jteh@mozilla.com James Teh], [mailto:mzehe@mozilla.com Marco Zehe], [mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|ownersemeritus=[mailto:aaron@moonset.net. Aaron Leventhal], [mailto:surkov.alexander@gmail.com Alexander Surkov]<br />
|peersemeritus=[mailto:dbolter@mozilla.com David Bolter], [mailto:tbsaunde+mozbugs@tbsaunde.org Trevor Saunders], [mailto:ginn.chen@oracle.com Ginn Chen], Evan Yan<br />
|group=dev-accessibility<br />
|source_dirs=accessible/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=Animation<br />
|description=Declarative animations: CSS animations, CSS transitions, Web Animations API, and off-main thread animations.<br />
|owner=[mailto:brian@birchill.co.jp Brian Birtles] (:birtles)<br />
|peers=[mailto:boris@mozilla.com Boris Chiou] (:boris), [mailto:hikezoe.birchill@mozilla.com Hiroyuki Ikezoe] (:hiro), [mailto:mwoodrow@mozilla.com Matt Woodrow] (:mattwoodrow)<br />
|group=dev-tech-layout<br />
|source_dirs=dom/animation; and animation-related and interpolation-related code in layout/style, gfx/layers, servo/components/style and servo/ports/gecko<br />
|components=Core::DOM::Animation, Core::CSS Transitions and Animations<br />
}}<br />
<br />
{{Module<br />
|name=Anti-Tracking<br />
|description=Tracking detection and content-blocking.<br />
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]<br />
|peers=[mailto:dlee@mozilla.com Dimi Lee], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:ewright@mozilla.com Erica Wright], [mailto:xeonchen@gmail.com Gary Chen], [mailto:jhofmann@mozilla.com Johann Hofmann], [mailto:tihuang@mozilla.com Tim Huang]<br />
|group=dev-platform<br />
|source_dirs=toolkit/components/antitracking/, several files under browser/ and netwerk/url-classifier/<br />
|components=Core::Privacy: Anti-Tracking<br />
}}<br />
<br />
{{Module<br />
|name=Browser WebAPI<br />
|description=Web API for rendering apps, browser windows and widgets.<br />
|owner=[mailto:Olli.Pettay@helsinki.fi Olli Pettay]<br />
|peers=[mailto:fabrice@mozilla.com Fabrice Desré]<br />
|ownersemeritus=[mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|group=dev-webapi<br />
|source_dirs=dom/browser-element/<br />
|url=<br />
|components=Core::DOM<br />
}}<br />
<br />
{{Module<br />
|name=Build and Release Tools<br />
|description=Tools related to build and release automation and configuration of release builds.<br />
|owner=[mailto:nthomas@mozilla.com Nick Thomas]<br />
|peers=[mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:coop@mozilla.com Chris Cooper]<br />
|group=release-engineering<br />
|source_dirs=browser/config/mozconfigs/, mobile/android/config/mozconfigs/, xulrunner/config/mozconfigs/, b2g/config/, tools/update-packaging/<br />
|url=https://wiki.mozilla.org/ReleaseEngineering<br />
|components=Release Engineering::*<br />
}}<br />
<br />
{{Module<br />
|name=Build Config<br />
|description=The build system for Gecko and several mozilla.org hosted Gecko-based applications.<br />
|owner=[mailto:mh@glandium.org Mike Hommey] (:glandium)<br />
|peers=[mailto:dmajor@mozilla.com David Major] (:dmajor), [mailto:rstewart@mozilla.com Ricky Stewart] (:ricky), [mailto:mhentges@mozilla.com Mitchell Hentges]<br />
|ownersemeritus=Chris Manchester (2019-2020), Gregory Szorc (2013-2019), Ted Mielczarek (2008-[https://blog.mozilla.org/ted/2013/03/07/gregory-szorc-is-now-the-build-config-module-owner/ 2013]), Benjamin Smedberg (???-[http://benjamin.smedbergs.us/blog/2008-04-30/more-changing-of-the-guard-ted-mielczarek/ 2008]), <br />
|peersemeritus=Ted Mielczarek, Ralph Giles, Gregory Szorc, Chris Manchester, Mike Shal, Nathan Froyd<br />
|group=dev-builds<br />
|source_dirs=build/, config/, python/mozbuild, tools/cross-commit, tools/cvs2hg-import.py, tools/cvsmgmt/, tools/elf-dynstr-gc/, tools/trees.pl, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/<br />
|url=http://www.mozilla.org/build/<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Code Analysis and Debugging Tools<br />
|description=Tools for debugging Mozilla code or for analyzing speed, memory use, and other characteristics of it.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=<br />
|group=dev-performance<br />
|source_dirs=tools/codesighs/, tools/debug/, tools/dreftool/, tools/dumpdeps/, tools/jprof/, tools/leak-gauge/, tools/leaky/, tools/memory/, tools/module-deps/, tools/performance/, tools/post_compile/, tools/preloader/, tools/rb/, tools/reorder/, tools/trace-malloc/, tools/uuiddeps/, <br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Content Security<br />
|description=Native content-based security features enforced in the ContentSecurityManager, including: Content Security Policy (CSP), Mixed Content Blocker (MCB), Referrer Policy, Subresource Integrity (SRI), Cross-Origin Resource Sharing (CORS) and top-level data: URI blocking.<br />
|owner=[mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]<br />
|peers=[mailto:tvyas@mozilla.com Tanvi Vyas], [mailto:dveditz@mozilla.com Dan Veditz], [mailto:amarchesini@mozilla.com Andrea Marchesini], [mailto:jkt@mozilla.com Jonathan Kingston], [mailto:tnguyen@mozilla.com Thomas Nguyen]<br />
|peersemeritus=[mailto:mozilla@sidstamm.com Sid Stamm], [mailto:jonas@sicking.cc Jonas Sicking], François Marier<br />
|group=dev-security<br />
|source_dirs=dom/security<br />
|components=Core::DOM: Security<br />
}}<br />
<br />
{{Module<br />
|name=Cookies<br />
|description=<br />
|owner=[mailto:amarchesini@mozilla.com Andrea Marchesini]<br />
|peers=[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:honzab.moz@firemni.cz Honza Bambas] <br />
|ownersemeritus=Monica Chew<br />
|peersemeritus=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]<br />
|group=dev-platform<br />
|source_dirs=netwerk/cookie/<br />
|url=<br />
|components=Core::Networking: Cookies<br />
}}<br />
<br />
{{Module<br />
|name=Permissions<br />
|description=<br />
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:amarchesini@mozilla.com Andrea Marchesini], [mailto:honzab.moz@firemni.cz Honza Bambas]<br />
|ownersemeritus=Monica Chew<br />
|peersemeritus=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]<br />
|group=dev-platform<br />
|source_dirs=extensions/permissions/<br />
|url=<br />
|components=Core :: Permission Manager<br />
}}<br />
<br />
{{Module<br />
|name=Cycle Collector<br />
|description=Code to break and collect objects within reference cycles<br />
|owner=[https://mozillians.org/en-US/u/mccr8/ Andrew McCreight]<br />
|peers=Peter Van der Beken, Olli Pettay<br />
|peersemeritus=David Baron<br />
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers<br />
|components=Core::XPCOM<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=C++/Rust usage, tools, and style<br />
|description=Aspects of C++ use such as language feature usage, standard library versions/usage, compiler/toolchain versions, formatting and naming style, and aspects of Rust use as needs arise<br />
|owner=[mailto:eakhgari@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:bballo@mozilla.com Botond Ballo], [mailto:glandium@mozilla.com Mike Hommey], [mailto:jwalden@mozilla.com Jeff Walden], [mailto:sgiesecke@mozilla.com Simon Giesecke]<br />
|source_dirs=non-third-party C++ and Rust code in the tree<br />
|components=Various components<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=docshell<br />
|description=<br />
|owner=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:nika@thelayzells.com Nika Layzell]<br />
|peers=[mailto:peterv@propagandism.org Peter Van der Beken], [mailto:afarre@mozilla.com Andreas Farre]<br />
|ownersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:justin.lebar@gmail.com Justin Lebar], [mailto:sawang@mozilla.com Samael Wang], [mailto:kyle@nonpolynomial.com Kyle Machulis]<br />
|group=dev-platform<br />
|source_dirs=docshell/, uriloader/<br />
|url=<br />
|components=Core::Document Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Document Object Model<br />
|description=<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:hsivonen@iki.fi Henri Sivonen], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:baku@mozilla.com Andrea Marchesini],<br />
[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:nika@thelayzells.com Nika Layzell], [mailto:afarre@mozilla.com Andreas Farre], [mailto:emilio@crisal.io Emilio Cobos], [mailto:asuth@mozilla.com Andrew Sutherland]<br />
|ownersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|peersemeritus=[mailto:justin.lebar@gmail.com Justin Lebar], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:bent.mozilla@gmail.com Ben Turner], [mailto:mounir@lamouri.fr Mounir Lamouri], [mailto:me@kylehuey.com Kyle Huey], [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:ben@wanderview.com Ben Kelly], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:kyle@nonpolynomial.com Kyle Machulis], [mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/*, except directories covered by other modules<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML<br />
}}<br />
<br />
{{Module<br />
|name=DOM File<br />
|description=DOM Blob, File and FileSystem APIs <br />
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]<br />
|peers=[mailto:olli@pettay.fi Olli Pettay]<br />
|group=dev-platform<br />
|source_dirs=dom/file, dom/filesystem<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: File<br />
}}<br />
<br />
{{Module<br />
|name=Event Handling<br />
|description=DOM Events and Event Handling <br />
|owner=[mailto:olli@pettay.fi Olli Pettay], [mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:echen@mozilla.com Edgar Chen]<br />
|peersemeritus=[mailto:sshih@mozilla.com Stone Shih]<br />
|group=dev-platform<br />
|source_dirs=dom/events and event handling related code elsewhere <br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: Events, Core::DOM: UI Events & Focus Handling<br />
}}<br />
<br />
{{Module<br />
|name=Web Workers<br />
|description=<br />
|owner=[mailto:asuth@mozilla.com Andrew Sutherland]<br />
|peers=[mailto:baku@mozilla.com Andrea Marchesini], [mailto:ytausky@mozilla.com Yaron Tausky]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|peersemeritus=[mailto:mrbkap@mozilla.com Blake Kaplan], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey], [mailto:bkelly@mozilla.com Ben Kelly]<br />
|group=dev-platform<br />
|source_dirs=dom/workers/<br />
|url=https://developer.mozilla.org/En/Using_web_workers<br />
|components=Core::DOM: Workers<br />
}}<br />
<br />
{{Module<br />
|name=IndexedDB<br />
|description=<br />
|owner=[mailto:jvarga@mozilla.com Jan Varga]<br />
|peers=[mailto:btseng@mozilla.com Bevis Tseng], [mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:baku@mozilla.com Andrea Marchesini]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey]<br />
|group=dev-platform<br />
|source_dirs=dom/indexedDB/<br />
|url=https://developer.mozilla.org/en/IndexedDB<br />
|components=Core::DOM: IndexedDB<br />
}}<br />
<br />
{{Module<br />
|name=Editor<br />
|description=<br />
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-platform<br />
|source_dirs=editor/<br />
|url=http://www.mozilla.org/editor/<br />
|components=Core::Editor<br />
}}<br />
<br />
{{Module<br />
|name=Gecko Profiler<br />
|description=Gecko's built-in profiler<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|peers=[mailto:gsquelart@mozilla.com Gerald Squelart], [mailto:gtatum@mozilla.com Greg Tatum], [mailto:canaltinova@mozilla.com Nazim Can Altinova], [mailto:jseward@mozilla.com Julian Seward] (LUL), [mailto:kvijayan@mozilla.com Kannan Vijayan] (JS integration), [mailto:brennie@mozilla.com Barret Rennie] (Screenshots).<br />
|ownersemeritus=[mailto:b56girard@gmail.com Benoit Girard]<br />
|peersemeritus=[mailto:shu@mozilla.com Shu-yu Guo] (JS integration), [mailto:tlee@mozilla.com Thinker Lee] (TaskTracer), [mailto:cyu@mozilla.com Cervantes Yu] (TaskTracer), Nicholas Nethercote<br />
|group=dev-platform<br />
|source_dirs=tools/profiler/<br />
|url=https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler<br />
|components=Core::Gecko Profiler<br />
}}<br />
<br />
{{Module<br />
|name=Global Key Bindings<br />
|description=Global hot keys in Mozilla for the browser, editor, mail-news and widgets. Does not include underlined menu accelerators and the like, as those are part of i18n.<br />
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|group=dev-accessibility<br />
|source_dirs=dom/events (and platform specific directories under it)<br />
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html<br />
|components=Core::Keyboard: Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Graphics<br />
|description=Mozilla graphics API<br />
|owner=[mailto:jrmuizel@mozilla.com Jeff Muizelaar](Thebes, QCMS, YCbCr, Cairo/Pixman, Regions, OS X, Other)<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:bas.schouten@live.nl Bas Schouten](Layers, Windows), [mailto:jgilbert@mozilla.com Jeff Gilbert](WebGL, ANGLE), [mailto:mwoodrow@mozilla.com Matt Woodrow](Layers API), [mailto:jfkthame@googlemail.com Jonathan Kew](text/fonts), [mailto:nsilva@mozilla.com Nicolas Silva](MozSurface), [mailto:ncameron@mozilla.com Nick Cameron], [mailto:sikeda@mozilla.com Sotaro Ikeda](B2G), [mailto:jnicol@mozilla.com Jamie Nicol](Android), [mailto:snorp@mozilla.com James Willcox](Android), [mailto:mstange@themasta.com Markus Stange](OS X), [mailto:lsalzman@mozilla.com Lee Salzman](Skia, Canvas2D), [mailto:rhunt@mozilla.com Ryan Hunt](OMTP), [mailto:gwatson@mozilla.com Glenn Watson ](WebRender), [mailto:dmalyshau@mozilla.com Dzmitry Malyshau](WebRender)<br />
|peersemeritus=[mailto:bgirard@mozilla.com Benoit Girard](Compositor, Performance), [mailto:ajuma.bugzilla@alijuma.com Ali Juma], [mailto:george@mozilla.com George Wright](Canvas2D), [mailto:mchang@mozilla.com Mason Chang], [mailto:dvander@mozilla.com David Anderson], [mailto:clord@mozilla.com Christopher Lord], [mailto:jdaggett@mozilla.com John Daggett](text/fonts), [mailto:bjacob@mozilla.com Benoit Jacob](gfx/gl), [mailto:jdrew@mozilla.com Joe Drew], [mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=gfx/, dom/canvas/<br />
|url=https://wiki.mozilla.org/Platform/GFX https://wiki.mozilla.org/Gecko:Layers https://wiki.mozilla.org/Gecko:2DGraphicsSketch<br />
|components=Core::Graphics, Core::Graphics: Layers, Core::Graphics: Text, Core::Graphics: WebRender, Core::GFX: Color Management, Core::Canvas: 2D, Core::Canvas: WebGL<br />
}}<br />
<br />
{{Module<br />
|name=WebGPU (Graphics submodule)<br />
|description=WebGPU implementation<br />
|owner=[mailto:dmalyshau@mozilla.com Dzmitry Malyshau]<br />
|peers=[mailto:josh@joshgroves.com Joshua Groves], [mailto:jgilbert@mozilla.com Jeff Gilbert],<br />
|group=dev-platform<br />
|source_dirs=dom/webgpu<br />
|url=https://wiki.mozilla.org/Platform/GFX/WebGPU<br />
|components=Core::Graphics::WebGPU<br />
}}<br />
<br />
{{Module<br />
|name=APZ (Graphics submodule)<br />
|description=Asynchronous panning and zooming<br />
|owner=[mailto:bballo@mozilla.com Botond Ballo]<br />
|ownersemeritus=[mailto:kgupta@mozilla.staktrace.com Kartikaya Gupta]<br />
|peers=[mailto:kgupta@mozilla.staktrace.com Kartikaya Gupta], [mailto:tnikkel@mozilla.com Timothy Nikkel], [mailto:rhunt@mozilla.com Ryan Hunt], [mailto:mstange@mozilla.com Markus Stange]<br />
|group=dev-platform<br />
|source_dirs=gfx/layers/apz<br />
|url=https://wiki.mozilla.org/Platform/GFX/APZ<br />
|components=Core::Panning and Zooming<br />
}}<br />
<br />
{{Module<br />
|name=Moz2D (Graphics submodule)<br />
|description=Platform independent 2D graphics API<br />
|owner=[mailto:bschouten@mozilla.com Bas Schouten]<br />
|peers=[mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:gwright@mozilla.com George Wright], [mailto:jwatt@jwatt.org Jonathan Watt]<br />
|group=dev-platform<br />
|source=gfx/2d<br />
|url=https://wiki.mozilla.org/Platform/GFX/Moz2D<br />
|components=Core::Graphics<br />
}}<br />
<br />
{{Module<br />
|name=Legacy HTML Parser<br />
|description=<br />
|owner=[mailto:mrbkap@gmail.com Blake Kaplan]<br />
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:rbs@maths.uq.edu.au rbs@maths.uq.edu.au]<br />
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|source_dirs=parser/htmlparser<br />
|url=http://www.mozilla.org/newlayout/doc/parser.html<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=HAL<br />
|description=Hardware Abstraction Layer<br />
|owner=[mailto:gsvelto@mozilla.com Gabriele Svelto]<br />
|peers=<br />
|group=dev-platform<br />
|source_dirs=hal/<br />
|components=Core::Hardware Abstraction Layer (HAL)<br />
}}<br />
<br />
{{Module<br />
|name=HTML Parser<br />
|description=The HTML Parser transforms HTML source code into a DOM. It conforms to the HTML specification, and is mostly translated automatically from Java to C++.<br />
|owner=[mailto:hsivonen@iki.fi Henri Sivonen]<br />
|peers=[mailto:wchen@mozilla.com William Chen]<br />
|group=dev-platform<br />
|source_dirs=parser/html<br />
|url=http://about.validator.nu/<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=I18N Library<br />
|description=<br />
|owner=[mailto:hsivonen@hsivonen.fi Henri Sivonen (encoding)], [mailto:jfkthame@gmail.com Jonathan Kew (except to encoding)]<br />
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura], [mailto:gandalf@aviary.pl Zibi Braniecki], [mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]<br />
|ownersemeritus=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]<br />
|group=dev-i18n<br />
|source_dirs=intl/<br />
|url=http://mozilla.org/projects/intl/index.html<br />
|components=Core::Internationalization<br />
}}<br />
<br />
{{Module<br />
|name=ImageLib<br />
|description=<br />
|owner=[mailto:tnikkel@gmail.com Timothy Nikkel]<br />
|peers=[mailto:aosmond@mozilla.com Andrew Osmond], [mailto:jmuizelaar@mozilla.com Jeff Muizelaar]<br />
|peersemeritus=[mailto:seth.bugzilla@blackhail.net Seth Fowler], [mailto:netzen@gmail.com Brian Bondy], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-platform<br />
|source_dirs=media/libjpeg/, media/libpng/, image/, modules/zlib/<br />
|url=<br />
|components=Core::ImageLib<br />
}}<br />
<br />
{{Module<br />
|name=IPC<br />
|description=Native message-passing between threads and processes<br />
|owner=[mailto:jld@mozilla.com Jed Davis]<br />
|ownersemeritus=Chris Jones, Bill McCloskey<br />
|peers=[mailto:nika@thelayzells.com Nika Layzell], [mailto:jmathies@mozilla.com Jim Mathies], [mailto:amccreight@mozilla.com Andrew McCreight]<br />
|peersemeritus=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bent.mozilla@gmail.com Ben Turner], David Anderson, Kan-Ru Chen, Bevis Tseng, Ben Kelly<br />
|group=dev-platform<br />
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/<br />
|url=<br />
|components=Core::IPC}}<br />
<br />
{{Module<br />
|name=JavaScript<br />
|description=JavaScript engine (SpiderMonkey)<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:jdemooij@mozilla.com Jan de Mooij], André Bargull, [mailto:tcampbell@mozilla.com Ted Campbell], [mailto:jcoppeard@mozilla.com Jon Coppeard], [mailto:sphink@gmail.com Steve Fink], [mailto:arai.unmht@gmail.com Tooru Fujisawa], [mailto:evilpies@gmail.com Tom Schuster], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:jwalden@mit.edu Jeff Walden], [mailto:ystartsev@mozilla.com Yulia Startsev], [mailto:mgaudet@mozilla.com Matthew Gaudet], [mailto:iireland@mozilla.com Iain Ireland], [mailto:nicolas.b.pierron@mozilla.com Nicolas Pierron], [mailto:ccullen@mozilla.com Caroline Cullen], [mailto:nfitzgerald@mozilla.com Nick Fitzgerald], [mailto:luke@mozilla.com Luke Wagner], [mailto:sunfish@mozilla.com Dan Gohman], [mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peersemeritus=[mailto:brendan@mozilla.org Brendan Eich], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:nmatsakis@mozilla.com Niko Matsakis], [mailto:ejpbruel@mozilla.com Eddy Bruel], [mailto:danderson@mozilla.com David Anderson], [mailto:igor@mir2.org Igor Bukanov], Andreas Gal, [mailto:efaust@mozilla.com Eric Faust], [mailto:khyperia@mozilla.com Ashley Hauck], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:till@tillschneidereit.net Till Schneidereit], Nicholas Nethercote<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src<br />
|url=http://www.mozilla.org/js/spidermonkey,<br />
http://developer.mozilla.org/en/docs/About_JavaScript<br />
|components=Core::JavaScript Engine<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript JIT<br />
|description=JavaScript engine's JIT compilers (IonMonkey, Baseline)<br />
|owner=[mailto:jdemooij@mozilla.com Jan de Mooij]<br />
|peers=André Bargull, [mailto:bbouvier@mozilla.com Benjamin Bouvier], [mailto:tcampbell@mozilla.com Ted Campbell], [mailto:ccullen@mozilla.com Caroline Cullen], [mailto:mgaudet@mozilla.com Matthew Gaudet], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:iireland@mozilla.com Iain Ireland], [mailto:nicolas.b.pierron@mozilla.com Nicolas Pierron], [mailto:evilpies@gmail.com Tom Schuster], [mailto:sstangl@mozilla.com Sean Stangl], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:luke@mozilla.com Luke Wagner]<br />
|peersemeritus=[mailto:danderson@mozilla.com David Anderson], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:hv1989@gmail.com Hannes Verschore]<br />
|group=dev-tech-js-engine-internals<br />
|source_dirs=js/src/jit<br />
|url=http://www.mozilla.org/js/spidermonkey<br />
|components=Core::JavaScript Engine: JIT<br />
}}<br />
<br />
{{Module<br />
|name=jsat<br />
|description=Javascript screen reader that is used in Android and B2G<br />
|owner=[mailto:eitan@monotonous.org Eitan Isaacson]<br />
|peers=[mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|group=dev-accessibility<br />
|source_dirs=accessible/jsat/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=js-ctypes<br />
|description=A foreign function interface which allows privileged JS code to interact with binary code without using XPCOM/XPConnect.<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src/ctypes/<br />
|url=https://wiki.mozilla.org/JSctypes<br />
|components=Core::js-ctypes<br />
}}<br />
<br />
{{Module<br />
|name=js-tests<br />
|description=JavaScript test suite<br />
|owner=[mailto:bclary@bclary.com Bob Clary]<br />
|peers=<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tests/<br />
|url=http://www.mozilla.org/js/tests/library.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Layout Engine<br />
|description=rendering tree construction, layout (reflow), etc.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:jfkthame@gmail.com Jonathan Kew], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:matt.woodrow@gmail.com Matt Woodrow], [mailto:xidorn+moz@upsuper.org Xidorn Quan], [mailto:emilio@crisal.io Emilio Cobos Álvarez]<br />
|peersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/printing/, layout/tables/, layout/tools/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Layout<br />
|components=Core::Layout, Core::Layout: Block and Inline, Core::Layout: Columns, Core::Layout: Flexbox, Core::Layout: Floats, Core::Layout: Form Controls, Core::Layout: Generated Content, Lists, and Counters, Core::Layout: Grid, Core::Layout: Images, Video, and HTML Frames, Core::Layout: Positioned, Core::Layout: Ruby, Core::Layout: Scrolling and Overflow, Core::Layout: Tables, Core::Layout: Text and Fonts, Core::Print Preview, Core::Printing: Output<br />
}}<br />
<br />
{{Module<br />
|name=libjar<br />
|description=The JAR handling code (protocol handler, stream implementation, and zipreader/zipwriter).<br />
|owner=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|ownersemeritus=Taras Glek, Michael Wu<br />
|peers=[mailto:mnovotny@mozilla.com Michal Novotny], [mailto:vgosu@mozilla.com Valentin Gosu]<br />
|group=dev-platform<br />
|source_dirs=modules/libjar<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MathML<br />
|description=MathML is a low-level specification for describing mathematics which provides a foundation for the inclusion of mathematical expressions in Web pages.<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-tech-mathml<br />
|source_dirs=layout/mathml/<br />
|url=http://www.mozilla.org/projects/mathml/<br />
|components=Core::MathML<br />
}}<br />
<br />
{{Module<br />
|name=Media Playback<br />
|description=HTML Media APIs, including Media Source Extensions and non-MSE video/audio element playback, and Encrypted Media Extensions. (WebRTC and WebAudio not included).<br />
|owner=[mailto:jyavenard@mozilla.com Jean-Yves Avenard]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:cpearce@mozilla.com Chris Pearce]<br />
|peers=[mailto:kinetik@flim.org Matthew Gregan], [mailto:bvandyk@mozilla.com Bryce Van Dyk], [mailto:jolin@mozilla.com John Lin], [mailto:alwu@mozilla.com Alastor Wu], [mailto:jwwang@mozilla.com JW Wang]<br />
|group=dev-media<br />
|source_dirs=dom/media, media/gmp-clearkey/, media/libcubeb/, media/libnestegg/, media/libogg/, media/libopus/, media/libstagefright/, media/libtheora/, media/libtremor/, media/libvorbis/, media/libvpx/, media/omx-plugin/, media/rlz/<br />
|url=<br />
|components=Core::Audio/Video<br />
}}<br />
<br />
{{Module<br />
|name=Media Transport<br />
|description=Pluggable transport for real-time media<br />
|owner=[mailto:ekr@rtfm.com Eric Rescorla]<br />
|peers=[mailto:bcampen@mozilla.com Byron Campen], [mailto:abr@mozilla.com Adam Roach], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]<br />
|group=dev-media<br />
|source_dirs=media/mtransport<br />
|url=<br />
|components=Core::WebRTC::Networking<br />
}}<br />
<br />
{{Module<br />
|name=Memory Allocator<br />
|description=Most things related to memory allocation in Gecko, including jemalloc, replace-malloc, DMD (dark matter detector), logalloc, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=<br />
|peersemeritus=Eric Rahm, Nicholas Nethercote<br />
|group=dev-platform<br />
|source_dirs=memory/<br />
|components=Core::DMD, Core::jemalloc<br />
}}<br />
<br />
{{Module<br />
|name=mfbt<br />
|description=mfbt is a collection of headers, macros, data structures, methods, and other functionality available for use and reuse throughout all Mozilla code (including SpiderMonkey and Gecko more broadly).<br />
|owner=[mailto:jwalden@mit.edu Jeff Walden]<br />
|peers=[mailto:Ms2ger@gmail.com Ms2ger], [mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|group=dev-platform<br />
|source_dirs=mfbt/<br />
|url=<br />
|components=Core::MFBT<br />
}}<br />
<br />
{{Module<br />
|name=Mozglue<br />
|description=Glue library containing various low-level functionality, including a dynamic linker for Android, a DLL block list for Windows, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:kgupta@mozilla.com Kartikaya Gupta] (mozglue/android), [mailto:nchen@mozilla.com Jim Chen] (mozglue/android), [mailto:aklotz@mozilla.com Aaron Klotz] (Windows Dll Blocklist/Interceptor)<br />
|group=dev-platform<br />
|source_dirs=mozglue/<br />
|components=Core::mozglue<br />
}}<br />
<br />
{{Module<br />
|name=mozilla-toplevel<br />
|description=The top level directory for the mozilla tree.<br />
|owner=[[Modules/Firefox_Technical_Leadership|Firefox Technical Leadership module]]<br />
|ownersemeritus=[mailto:brendan@mozilla.org Brendan Eich]<br />
|peers=<br />
|group=<br />
|source_dirs=tools/README<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MSCOM<br />
|description=Integration with Microsoft Distributed COM<br />
|owner=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|peers=[mailto:jteh@mozilla.com James Teh], [mailto:jmathies@mozilla.com Jim Mathies]<br />
|group=dev-platform<br />
|source_dirs=ipc/mscom/%<br />
|url=<br />
|components=Core::IPC: MSCOM}}<br />
<br />
{{Module<br />
|name=Necko<br />
|description=The Mozilla Networking Library<br />
|owner=[mailto:dd.mozilla@gmail.com Dragana Damjanovic]<br />
|peers= [mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:mnovotny@mozilla.com Michal Novotny], [mailto:valentin.gosu@gmail.com Valentin Gosu], [mailto:kershaw@mozilla.com Kershaw Chang], [mailto:juhsu@mozilla.com Junior Hsu]<br />
|ownersemeritus=[mailto:mcmanus@ducksong.com Patrick McManus], [mailto:cbiesinger@gmail.com Christian Biesinger] |peersemeritus= Shih-Chiang Chien, [mailto:bzbarsky@mit.edu Boris Zbarsky], Steve Workman, Nick Hurley, [mailto:daniel@haxx.se Daniel Stenberg ], [mailto:jduell.mcbugs@gmail.com Jason Duell]<br />
|group=dev-tech-network<br />
|source_dirs=netwerk/%, netwerk/base/, netwerk/build/, netwerk/cache/, netwerk/dns/, netwerk/locales/, netwerk/mime/, netwerk/protocol/, netwerk/resources/, netwerk/socket/, netwerk/streamconv/, netwerk/system/, netwerk/test/, netwerk/testserver/<br />
|url=http://www.mozilla.org/projects/netlib/, https://developer.mozilla.org/en/Necko<br />
|components=Core::Networking, Core::Networking: Cache, Core::Networking: Cookies, Core::Networking: FTP, Core::Networking: File, Core::Networking: HTTP, Core::Networking: JAR, Core::Networking: Websockets<br />
}}<br />
<br />
{{Module<br />
|name=NodeJS usage, tools, and style<br />
|description=Advises on the use of NodeJS and npm packages at build and runtime. Reviews additions/upgrades/removals of vendored npm packages. Works with appropriate teams to maintain automated license and security audits of npm packages. Works with the security team and relevant developers to respond to vulnerabilities in NodeJS and vendored npm packages.<br />
|owner=[mailto:dmosedale@mozilla.com Dan Mosedale]<br />
|peers=[mailto:mbanner@mozilla.com Mark Banner], [mailto:dcoates@mozilla.com Danny Coates], [mailto:khudson@mozilla.com Kate Hudson], [mailto:jlaster@mozilla.com Jason Laster], [mailto:elee@mozilla.com Ed Lee], [mailto:dtownsend@mozilla.com Dave Townsend]<br />
|source_dirs=package.json, package-lock.json, node_modules and others as appropriate<br />
|components=Various components<br />
|forum=[https://wiki.mozilla.org/Firefox/firefox-dev firefox-dev], #nodejs on slack<br />
}}<br />
<br />
{{Module<br />
|name=NSPR<br />
|description=Netscape Portable Runtime<br />
|owner=[mailto:kaie@kuix.de Kai Engert]<br />
|peers=[mailto:mh@glandium.org Mike Hommey]<br />
|ownersemeritus=[mailto:wtc@google.com Wan-Teh Chang]<br />
|group=dev-tech-nspr<br />
|source_dirs=nsprpub/<br />
|url=http://www.mozilla.org/projects/nspr/<br />
http://www.mozilla.org/projects/nspr/reference/html/<br />
http://www.mozilla.org/projects/nspr/release-notes/<br />
|components=NSPR<br />
}}<br />
<br />
{{Module<br />
|name=PDF<br />
|description=Rendering code to display documents encoded in the ISO 32000-1 `PDF' format.<br />
|owner=[mailto:bdahl@mozilla.com Brendan Dahl]<br />
|peers=[mailto:aadib@mozilla.com Artur Adib], [mailto:vnicolas@mozilla.com Vivien Nicolas]<br />
|group=dev-platform<br />
|source_dirs=media/pdf/<br />
|url=https://github.com/mozilla/pdf.js<br />
|components=Core::PDF<br />
}}<br />
<br />
{{Module<br />
|name=Plugins<br />
|description= NPAPI Plugin support.<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:davidp99@gmail.com David Parks]<br />
|peersemeritus=[mailto:joshmoz@gmail.com Josh Aas], [mailto:john@pointysoftware.net John Schoenick], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:jstenback@gmail.com Johnny Stenback], Benjamin Smedberg<br />
|group=<br />
|source_dirs=dom/plugins/, modules/plugin/<br />
|url=https://wiki.mozilla.org/Plugins<br />
|components=Core::Plug-ins<br />
}}<br />
<br />
{{Module<br />
|name=Preferences<br />
|description=Preference library<br />
|owner=[mailto:kwright@mozilla.com Kris Wright]<br />
|peers=[mailto:glandium@mozilla.com Mike Hommey], [mailto:kwright@mozilla.com Kris Wright]<br />
|ownersemeritus=Nicholas Nethercote<br />
|peersemeritus=Felipe Gomes, Eric Rahm<br />
|group=dev-platform<br />
|source_dirs=modules/libpref/<br />
|url=<br />
|components=Core::Preferences: Backend<br />
}}<br />
<br />
{{Module<br />
|name=Private Browsing<br />
|description=Implementation of the Private Browsing mode, and the integration of other modules with Private Browsing APIs.<br />
|owner=[mailto:eakhgari@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:josh@joshmatthews.net Josh Matthews]<br />
|group=dev-platform<br />
|source_dirs=Implementation and consumers of Private Browsing APIs in nsILoadContext, nsIPrivateBrowsingChannel, PrivateBrowsingUtils.jsm and the related glue code. <br />
|url=https://wiki.mozilla.org/Private_Browsing<br />
|components=Firefox::Private Browsing<br />
}}<br />
<br />
{{Module<br />
|name=Privilege Manager<br />
|description="caps"<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]<br />
|peersemeritus=[mailto:brendan@mozilla.org Brendan Eich], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:dveditz@mozilla.com Dan Veditz]<br />
|group=dev-tech-dom<br />
|source_dirs=caps/<br />
|url=http://www.mozilla.org/projects/security/components/index.html<br />
|components=Core::Security: CAPS<br />
}}<br />
<br />
{{Module<br />
|name=Push Notifications<br />
|description=Push is a way for application developers to send messages to their web applications.<br />
|owners=[mailto:lina@mozilla.com Lina Cambridge]<br />
|ownersemeritus=[mailto:doug.turner@gmail.com Doug Turner]<br />
|peers=[mailto:mt@lowentropy.net Martin Thomson], [mailto:ddamjanovic@mozilla.com Dragana Damjanovic]<br />
|peersemeritus=[mailto:nsm.nikhil@gmail.com Nikhil Marathe]<br />
|group=<br />
|source_dirs=dom/push<br />
|url=<br />
|components=Core::DOM: Push Notifications<br />
}}<br />
<br />
{{Module<br />
|name=security<br />
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)<br />
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:mt@lowentropy.net Martin Thomson]<br />
|ownersemeritus=[mailto:wtc@google.com Wan-Teh Chang], [mailto:ttaubert@mozilla.com Tim Taubert]<br />
|peers=[mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi], [mailto:ekr@rtfm.com Eric Rescorla], [mailto:franziskuskiefer@gmail.com Franziskus Kiefer], [mailto:dueno@redhat.com Daiki Ueno]<br />
|peersemeritus=[mailto:emaldona@redhat.com Elio Maldonado]<br />
|group=dev-tech-crypto<br />
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/<br />
|url=http://mozilla.org/projects/security/pki/<br />
|components=NSS, JSS, Core::Security, Core::Security: S/MIME<br />
}}<br />
<br />
{{Module<br />
|name=Security - Mozilla PSM Glue<br />
|description=Personal Security Manager<br />
|owner=[mailto:dkeeler@mozilla.com Dana Keeler]<br />
|ownersemeritus=[mailto:kaie@kuix.de Kai Engert (2001-2012)]<br />
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:cykesiopka.bmo@gmail.com Cykesiopka], [mailto:jc@mozilla.com J.C. Jones], [mailto:fkiefer@mozilla.com Franziskus Kiefer]<br />
|group=dev-tech-crypto<br />
|source_dirs=security/manager/<br />
|url=<br />
|components=Core::Security: PSM<br />
}}<br />
<br />
{{Module<br />
|name=Static analysis & rewriting for C++<br />
|description=Tools for checking C++ code looking for problems at compile time, plus tools for automated rewriting of C++ code.<br />
|owner=[mailto:andi@mozilla.com Andi-Bogdan Postelnicu]<br />
|peers=[mailto:nika@thelayzells.com Nika Layzell], [mailto:sfink@mozilla.com Steve Fink], [mailto:jrmuizel@mozilla.com Jeff Muizelaar], [mailto:eakhgari@mozilla.com Ehsan Akhgari]<br />
|peersemeritus=[mailto:birunthan@mohanathas.com Birunthan Mohanathas]<br />
|group=dev-platform<br />
|source_dirs=build/clang-plugin, tools/rewriting among other out of tree tools<br />
|url=<br />
|components=Core::Rewriting & Analysis<br />
}}<br />
{{Module<br />
|name=storage<br />
|description=Storage APIs with a SQLite backend<br />
|owner=[mailto:mak77@bonardo.net Marco Bonardo]<br />
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:jvarga@mozilla.com Jan Varga]<br />
|group=dev-platform<br />
|source_dirs=db/sqlite3/, storage/<br />
|url=http://developer.mozilla.org/en/docs/Storage<br />
|components=Toolkit::Storage, Core::SQL<br />
}}<br />
<br />
{{Module<br />
|name=String<br />
|description=<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-tech-xpcom<br />
|source_dirs=string/, xpcom/string/<br />
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide<br />
|components=Core::String<br />
}}<br />
<br />
{{Module<br />
|name=Style System<br />
|description=CSS style sheet handling; style data computation<br />
|owner=[mailto:cam@mcc.id.au Cameron McCormack]<br />
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:emilio@crisal.io Emilio Cobos Álvarez], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:xidorn+moz@upsuper.org Xidorn Quan], [mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/style/, servo/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System<br />
|components=Core::CSS Parsing and Computation<br />
}}<br />
<br />
{{Module<br />
|name=SVG<br />
|description=Scalable Vector Graphics<br />
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]<br />
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]<br />
|group=dev-tech-svg<br />
|source_dirs=dom/svg/, layout/svg/, dom/smil/<br />
|url=https://developer.mozilla.org/en-US/docs/Web/SVG<br />
|components=Core::SVG<br />
}}<br />
<br />
{{Module<br />
|name=View System<br />
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]<br />
|group=dev-tech-layout<br />
|source_dirs=view/<br />
|url=<br />
|components=Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=Web Audio<br />
|description=Support for the W3C Web Audio API specification.<br />
|owner=[mailto:padenot@mozilla.com Paul Adenot]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:karlt+@karlt.net Karl Tomlinson]<br />
|group=dev-platform<br />
|source_dirs=dom/media/webaudio<br />
|url=https://wiki.mozilla.org/Web_Audio_API<br />
|components=Core::Web Audio<br />
}}<br />
<br />
{{Module<br />
|name=Web Painting<br />
|description=painting, display lists, and layer construction<br />
|owner=[mailto:matt.woodrow@gmail.com Matt Woodrow]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dbaron@dbaron.org David Baron], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:mstange@themasta.com Markus Stange], [mailto:mmynttinen@mozilla.com Miko Mynttinen], [mailto:jnicol@mozilla.com Jamie Nicol]<br />
|group=dev-tech-layout<br />
|source_dirs= layout/painting, the display list and layer related methods on nsIFrame and its subclasses<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|components=Core::Layout: Web Painting<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC<br />
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=netwerk/sctp (also see submodules "WebRTC Media" and "WebRTC Signaling")<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC, Core::WebRTC Networking<br />
}}<br />
<br />
{{Module<br />
|name=WebVR<br />
|description=Gecko's implementation of WebVR (Virtual Reality) functionality, including API, devices, graphics and integration<br />
|owner=[mailto:kgilbert@mozilla.com Kearwood (Kip) Gilbert]<br />
|peers=[mailto:dmu@mozilla.com Daosheng Mu], [mailto:igorostizaga@mozilla.com Imanol Fernández]<br />
|peersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=dom/vr, gfx/vr<br />
|url=https://mozvr.com/<br />
|components=Core::WebVR<br />
}}<br />
<br />
{{Module<br />
|name=Widget<br />
|description=Top level Widget<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|ownersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peersemeritus=[mailto:pavlov@pavlov.net Stuart Parmenter], <br />
|group=dev-platform<br />
|source_dirs=widget/, widget/xpwidgets/<br />
|url=<br />
|components=Core::Drag and Drop, Core::Widget, Core::Printing: Setup<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Android<br />
|description=Android widget support<br />
|owner=[mailto:jwillcox@mozilla.com James Willcox]<br />
|peers=<br />
|ownersemeritus=[mailto:blassey.bugs@lassey.us Brad Lassey]<br />
|group=dev-platforms-mobile<br />
|source_dirs=widget/android/, embedding/android<br />
|url=<br />
|components=Core::Widget: Android<br />
}}<br />
<br />
{{Module<br />
|name=Widget - GTK<br />
|description=GTK widget support<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:stransky@redhat.com Martin Stránský]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-platform<br />
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/<br />
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/<br />
|components=Core::Widget: Gtk<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Headless<br />
|description=Headless widget support<br />
|owner=[mailto:bdahl@mozilla.com Brendan Dahl]<br />
|peers=<br />
|ownersemeritus=<br />
|group=dev-platform<br />
|source_dirs=widget/headless/<br />
|url=<br />
|components=Firefox::Headless<br />
}}<br />
<br />
{{Module<br />
|name=Widget - macOS<br />
|description= macOS widget support<br />
|owner=[mailto:spohl@mozilla.com Stephen A Pohl]<br />
|peers=[mailto:mstange@themasta.com Markus Stange], [mailto:haftandilian@mozilla.com Haik Aftandilian]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:mstange@themasta.com Markus Stange]<br />
|peersemeritus=[mailto:joshmoz@gmail.com Josh Aas], [mailto:b56girard@gmail.com Benoit Girard], [mailto:smichaud@pobox.com Steven Michaud]<br />
|group=dev-platform<br />
|source_dirs=widget/cocoa/<br />
|url=<br />
|components=Core::Widget: Cocoa<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Windows<br />
|description=Windows widget support<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:cmartin@mozilla.com Chris Martin], [mailto:tkikuchi@mozilla.com Toshihito Kikuchi], [mailto:mhowell@mozilla.com Molly Howell], [mailto:aklotz@mozilla.com Aaron Klotz], [mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|peersemeritus=[mailto:robert.strong.bugs@gmail.com Rob Strong], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:doug.turner@gmail.com Doug Turner], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:robarnold@cmu.edu Rob Arnold]<br />
|group=dev-platform<br />
|source_dirs=widget/windows/<br />
|url=<br />
|components=Core::Widget: Win32<br />
}}<br />
<br />
{{Module<br />
|name=XML<br />
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-xml<br />
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/<br />
|url=http://www.mozilla.org/newlayout/xml/<br />
|components=Core::XML<br />
}}<br />
<br />
{{Module<br />
|name=XPApps<br />
|description=Cross-Platform Applications, mostly Navigator front end and application shell.<br />
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-apps-seamonkey<br />
|source_dirs=xpfe/<br />
|url=http://www.mozilla.org/xpapps/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPCOM<br />
|description=The cross-platform object model and core data structures.<br />
|owner=[mailto:nika@thelayzells.com Nika Layzell]<br />
|peers=[mailto:erahm@mozilla.com Eric Rahm], [mailto:kmaglione@mozilla.com Kris Maglione], [mailto:sgiesecke@mozilla.com Simon Giesecke]<br />
|ownersemeritus=Benjamin Smedberg<br />
|peersemeritus=[https://mozillians.org/en-US/u/dougt/ Doug Turner]<br />
|group=dev-platform<br />
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/<br />
|url=http://developer.mozilla.org/en/XPCOM<br />
|components=Core::XPCOM<br />
}}<br />
<br />
{{Module<br />
|name=XPConnect<br />
|description=Deep Magic<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:kmaglione@mozilla.com Kris Maglione], [mailto:nika@thelayzells.com Nika Layzell]<br />
|peersemeritus=[mailto:gal@uci.edu Andreas Gal], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]<br />
|group=<br />
|source_dirs=js/xpconnect/<br />
|url=<br />
|components=Core::XPConnect<br />
}}<br />
<br />
{{Module<br />
|name=XPIDL<br />
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.<br />
|owner=[mailto:nika@thelayzells.com Nika Layzell]<br />
|peers=[mailto:amccreight@mozilla.com Andrew McCreight]<br />
|ownersemeritus=[mailto:me@kylehuey.com Kyle Huey]<br />
|peersemeritus=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-tech-xpcom<br />
|source_dirs=xpcom/typelib/<br />
|url=http://www.mozilla.org/scriptable/xpidl<br />
http://www.mozilla.org/scriptable<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XSLT Processor<br />
|description=XSLT transformations processor<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:axel@pike.org Axel Hecht]<br />
|group=dev-tech-xslt<br />
|source_dirs=dom/xslt/<br />
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html<br />
|components=Core::XSLT<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Windows <br />
|description=Sandboxing for the Windows platform <br />
|owner=[mailto:bobowencode@gmail.com Bob Owen] (:bobowen)<br />
|peers=[mailto:aklotz@mozilla.com Aaron Klotz] (:aklotz), [mailto:jimm@mozilla.com Jim Mathies] (:jimm), [mailto:davidp99@gmail.com David Parks] (:handyman)<br />
|ownersemeritus=[https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes]<br />
|peersemeritus=[mailto:netzen@gmail.com Brian Bondy]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/win <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - OSX <br />
|description=Sandboxing for the OSX platform <br />
|owner=[mailto:haftandilian@mozilla.com Haik Aftandilian]<br />
|peers=<br />
|group=dev-platform <br />
|source_dirs=security/sandbox/mac <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Linux<br />
|description=Sandboxing for the Linux platform<br />
|owner=[mailto:jld@mozilla.com Jed Davis]<br />
|peers=[mailto:gcp@mozilla.com Gian-Carlo Pascutto]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/linux<br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Crash reporting<br />
|description=Infrastructure and tools used to generate, submit and process crash reports. This includes the in-tree google-breakpad fork, the crash report generation machinery as well as the host tools used to dump symbols, analyse minidumps and generate stack traces.<br />
|owner=[mailto:gsvelto@mozilla.com Gabriele Svelto] (:gsvelto)<br />
|peers=<br />
|group=dev-platform<br />
|source_dirs=toolkit/crashreporter, toolkit/components/crashes, tools/crashreporter, ipc/glue/CrashReporter*, mobile/android/geckoview/src/main/java/org/mozilla/geckoview/CrashReporter.java<br />
|url=https://firefox-source-docs.mozilla.org/toolkit/crashreporter/crashreporter/index.html<br />
|components=Toolkit::Crash Reporting<br />
}}<br />
<br />
===Submodules===<br />
{{Module<br />
|name=Build Config - Fennec<br />
|description=Submodule of the build config covering Fennec's build system in mobile/android.<br />
|owner=[mailto:nalexander@mozilla.com Nicholas Alexander]<br />
|peers=Same as Build Config<br />
|group=dev-builds<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Build Config - Taskgraph<br />
|description=Support for task-graph generation in decision, action, and cron tasks, including configuration of all tasks including those for CI, nightlies, and releases; as well as Docker and VM images used to execute those tasks.<br />
|owner=[mailto:mozilla@hocat.ca Tom Prince]<br />
|peers=[mailto:ahal@mozilla.com Andrew Halberstadt], [mailto:aki@mozilla.com Aki Sasaki], [mailto:bstack@mozilla.com Brian Stack], [mailto:mh@glandium.org Mike Hommey], [mailto:gps@mozilla.com Gregory Szorc], [mailto:jmaher@mozilla.com Joel Maher], [mailto:callek@mozilla.com Justin Wood], [mailto:dustin@mozilla.com Dustin Mitchell]<br />
|components=Firefox Build System::Task Configuration<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Media<br />
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:jib@mozilla.com Jan-Ivar Bruaroey], [mailto:dminor@mozilla.com Dan Minor], [mailto:apehrson@mozilla.com Andreas Pehrson], <br />
|peersemeritus=[mailto:pkerr@mozilla.com Paul Kerr], [mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc, /dom/media/webrtc, /dom/media/systemservices<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Audio/Video)<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Signaling<br />
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling<br />
|owner=[mailto:bcampen@mozilla.com Byron Campen]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:abr@mozilla.com Adam Roach], [mailto:rjesup@mozilla.com Randell Jesup], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc/signaling/<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Signaling)<br />
}}<br />
<br />
<noinclude><br />
<br />
===Unassigned Bugzilla Components===<br />
<br />
The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):<br />
<br />
<pre><br />
Core::Find Backend<br />
Core::General<br />
Core::History: Global<br />
Core::Image Blocking<br />
Core::Localization<br />
Core::Networking: Domain Lists<br />
Core::Selection<br />
Core::Serializers<br />
Core::Spelling checker<br />
Core::X-remote<br />
Core::XUL<br />
</pre><br />
</noinclude></div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Modules/Core&diff=1232419Modules/Core2020-11-29T20:04:04Z<p>Nnethercote: </p>
<hr />
<div><noinclude><br />
'''Only module owners may edit this page.''' <br />
<br />
They may:<br />
<br />
* update any information about their module except the name of the owner<br />
* add or remove sub-modules<br />
* change the owner of a sub-module <br />
* add emeritus owners or peers<br />
<br />
Other changes, including changes of module owner or addition/removal of modules, must be agreed with the Module Ownership Module group, probably via a discussion in [https://www.mozilla.org/about/forums/#governance mozilla.governance].<br />
</noinclude><br />
{{Module<br />
|name=Accessibility<br />
|description=Support for platform accessibility APIs. Accessibility APIs are used by 3rd party software like screen readers, screen magnifiers, and voice dictation software, which need information about document content and UI controls, as well as important events like changes of focus.<br />
|owner=[mailto:jteh@mozilla.com Jamie Teh]<br />
|peers=[mailto:eitan@monotonous.org Eitan Isaacson], [mailto:jteh@mozilla.com James Teh], [mailto:mzehe@mozilla.com Marco Zehe], [mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|ownersemeritus=[mailto:aaron@moonset.net. Aaron Leventhal], [mailto:surkov.alexander@gmail.com Alexander Surkov]<br />
|peersemeritus=[mailto:dbolter@mozilla.com David Bolter], [mailto:tbsaunde+mozbugs@tbsaunde.org Trevor Saunders], [mailto:ginn.chen@oracle.com Ginn Chen], Evan Yan<br />
|group=dev-accessibility<br />
|source_dirs=accessible/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=Animation<br />
|description=Declarative animations: CSS animations, CSS transitions, Web Animations API, and off-main thread animations.<br />
|owner=[mailto:brian@birchill.co.jp Brian Birtles] (:birtles)<br />
|peers=[mailto:boris@mozilla.com Boris Chiou] (:boris), [mailto:hikezoe.birchill@mozilla.com Hiroyuki Ikezoe] (:hiro), [mailto:mwoodrow@mozilla.com Matt Woodrow] (:mattwoodrow)<br />
|group=dev-tech-layout<br />
|source_dirs=dom/animation; and animation-related and interpolation-related code in layout/style, gfx/layers, servo/components/style and servo/ports/gecko<br />
|components=Core::DOM::Animation, Core::CSS Transitions and Animations<br />
}}<br />
<br />
{{Module<br />
|name=Anti-Tracking<br />
|description=Tracking detection and content-blocking.<br />
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]<br />
|peers=[mailto:dlee@mozilla.com Dimi Lee], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:ewright@mozilla.com Erica Wright], [mailto:xeonchen@gmail.com Gary Chen], [mailto:jhofmann@mozilla.com Johann Hofmann], [mailto:tihuang@mozilla.com Tim Huang]<br />
|group=dev-platform<br />
|source_dirs=toolkit/components/antitracking/, several files under browser/ and netwerk/url-classifier/<br />
|components=Core::Privacy: Anti-Tracking<br />
}}<br />
<br />
{{Module<br />
|name=Browser WebAPI<br />
|description=Web API for rendering apps, browser windows and widgets.<br />
|owner=[mailto:Olli.Pettay@helsinki.fi Olli Pettay]<br />
|peers=[mailto:fabrice@mozilla.com Fabrice Desré]<br />
|ownersemeritus=[mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|group=dev-webapi<br />
|source_dirs=dom/browser-element/<br />
|url=<br />
|components=Core::DOM<br />
}}<br />
<br />
{{Module<br />
|name=Build and Release Tools<br />
|description=Tools related to build and release automation and configuration of release builds.<br />
|owner=[mailto:nthomas@mozilla.com Nick Thomas]<br />
|peers=[mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:coop@mozilla.com Chris Cooper]<br />
|group=release-engineering<br />
|source_dirs=browser/config/mozconfigs/, mobile/android/config/mozconfigs/, xulrunner/config/mozconfigs/, b2g/config/, tools/update-packaging/<br />
|url=https://wiki.mozilla.org/ReleaseEngineering<br />
|components=Release Engineering::*<br />
}}<br />
<br />
{{Module<br />
|name=Build Config<br />
|description=The build system for Gecko and several mozilla.org hosted Gecko-based applications.<br />
|owner=[mailto:mh@glandium.org Mike Hommey] (:glandium)<br />
|peers=[mailto:dmajor@mozilla.com David Major] (:dmajor), [mailto:rstewart@mozilla.com Ricky Stewart] (:ricky), [mailto:mhentges@mozilla.com Mitchell Hentges]<br />
|ownersemeritus=Chris Manchester (2019-2020), Gregory Szorc (2013-2019), Ted Mielczarek (2008-[https://blog.mozilla.org/ted/2013/03/07/gregory-szorc-is-now-the-build-config-module-owner/ 2013]), Benjamin Smedberg (???-[http://benjamin.smedbergs.us/blog/2008-04-30/more-changing-of-the-guard-ted-mielczarek/ 2008]), <br />
|peersemeritus=Ted Mielczarek, Ralph Giles, Gregory Szorc, Chris Manchester, Mike Shal, Nathan Froyd<br />
|group=dev-builds<br />
|source_dirs=build/, config/, python/mozbuild, tools/cross-commit, tools/cvs2hg-import.py, tools/cvsmgmt/, tools/elf-dynstr-gc/, tools/trees.pl, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/<br />
|url=http://www.mozilla.org/build/<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Code Analysis and Debugging Tools<br />
|description=Tools for debugging Mozilla code or for analyzing speed, memory use, and other characteristics of it.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=<br />
|group=dev-performance<br />
|source_dirs=tools/codesighs/, tools/debug/, tools/dreftool/, tools/dumpdeps/, tools/jprof/, tools/leak-gauge/, tools/leaky/, tools/memory/, tools/module-deps/, tools/performance/, tools/post_compile/, tools/preloader/, tools/rb/, tools/reorder/, tools/trace-malloc/, tools/uuiddeps/, <br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Content Security<br />
|description=Native content-based security features enforced in the ContentSecurityManager, including: Content Security Policy (CSP), Mixed Content Blocker (MCB), Referrer Policy, Subresource Integrity (SRI), Cross-Origin Resource Sharing (CORS) and top-level data: URI blocking.<br />
|owner=[mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]<br />
|peers=[mailto:tvyas@mozilla.com Tanvi Vyas], [mailto:dveditz@mozilla.com Dan Veditz], [mailto:amarchesini@mozilla.com Andrea Marchesini], [mailto:jkt@mozilla.com Jonathan Kingston], [mailto:tnguyen@mozilla.com Thomas Nguyen]<br />
|peersemeritus=[mailto:mozilla@sidstamm.com Sid Stamm], [mailto:jonas@sicking.cc Jonas Sicking], François Marier<br />
|group=dev-security<br />
|source_dirs=dom/security<br />
|components=Core::DOM: Security<br />
}}<br />
<br />
{{Module<br />
|name=Cookies<br />
|description=<br />
|owner=[mailto:amarchesini@mozilla.com Andrea Marchesini]<br />
|peers=[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:honzab.moz@firemni.cz Honza Bambas] <br />
|ownersemeritus=Monica Chew<br />
|peersemeritus=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]<br />
|group=dev-platform<br />
|source_dirs=netwerk/cookie/<br />
|url=<br />
|components=Core::Networking: Cookies<br />
}}<br />
<br />
{{Module<br />
|name=Permissions<br />
|description=<br />
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:amarchesini@mozilla.com Andrea Marchesini], [mailto:honzab.moz@firemni.cz Honza Bambas]<br />
|ownersemeritus=Monica Chew<br />
|peersemeritus=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]<br />
|group=dev-platform<br />
|source_dirs=extensions/permissions/<br />
|url=<br />
|components=Core :: Permission Manager<br />
}}<br />
<br />
{{Module<br />
|name=Cycle Collector<br />
|description=Code to break and collect objects within reference cycles<br />
|owner=[https://mozillians.org/en-US/u/mccr8/ Andrew McCreight]<br />
|peers=Peter Van der Beken, Olli Pettay<br />
|peersemeritus=David Baron<br />
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers<br />
|components=Core::XPCOM<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=C++/Rust usage, tools, and style<br />
|description=Aspects of C++ use such as language feature usage, standard library versions/usage, compiler/toolchain versions, formatting and naming style, and aspects of Rust use as needs arise<br />
|owner=[mailto:eakhgari@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:bballo@mozilla.com Botond Ballo], [mailto:glandium@mozilla.com Mike Hommey], [mailto:jwalden@mozilla.com Jeff Walden], [mailto:sgiesecke@mozilla.com Simon Giesecke]<br />
|source_dirs=non-third-party C++ and Rust code in the tree<br />
|components=Various components<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=docshell<br />
|description=<br />
|owner=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:nika@thelayzells.com Nika Layzell]<br />
|peers=[mailto:peterv@propagandism.org Peter Van der Beken], [mailto:afarre@mozilla.com Andreas Farre]<br />
|ownersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:justin.lebar@gmail.com Justin Lebar], [mailto:sawang@mozilla.com Samael Wang], [mailto:kyle@nonpolynomial.com Kyle Machulis]<br />
|group=dev-platform<br />
|source_dirs=docshell/, uriloader/<br />
|url=<br />
|components=Core::Document Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Document Object Model<br />
|description=<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:hsivonen@iki.fi Henri Sivonen], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:baku@mozilla.com Andrea Marchesini],<br />
[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:nika@thelayzells.com Nika Layzell], [mailto:afarre@mozilla.com Andreas Farre], [mailto:emilio@crisal.io Emilio Cobos], [mailto:asuth@mozilla.com Andrew Sutherland]<br />
|ownersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|peersemeritus=[mailto:justin.lebar@gmail.com Justin Lebar], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:bent.mozilla@gmail.com Ben Turner], [mailto:mounir@lamouri.fr Mounir Lamouri], [mailto:me@kylehuey.com Kyle Huey], [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:ben@wanderview.com Ben Kelly], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:kyle@nonpolynomial.com Kyle Machulis], [mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/*, except directories covered by other modules<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML<br />
}}<br />
<br />
{{Module<br />
|name=DOM File<br />
|description=DOM Blob, File and FileSystem APIs <br />
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]<br />
|peers=[mailto:olli@pettay.fi Olli Pettay]<br />
|group=dev-platform<br />
|source_dirs=dom/file, dom/filesystem<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: File<br />
}}<br />
<br />
{{Module<br />
|name=Event Handling<br />
|description=DOM Events and Event Handling <br />
|owner=[mailto:olli@pettay.fi Olli Pettay], [mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:echen@mozilla.com Edgar Chen]<br />
|peersemeritus=[mailto:sshih@mozilla.com Stone Shih]<br />
|group=dev-platform<br />
|source_dirs=dom/events and event handling related code elsewhere <br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: Events, Core::DOM: UI Events & Focus Handling<br />
}}<br />
<br />
{{Module<br />
|name=Web Workers<br />
|description=<br />
|owner=[mailto:asuth@mozilla.com Andrew Sutherland]<br />
|peers=[mailto:baku@mozilla.com Andrea Marchesini], [mailto:ytausky@mozilla.com Yaron Tausky]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|peersemeritus=[mailto:mrbkap@mozilla.com Blake Kaplan], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey], [mailto:bkelly@mozilla.com Ben Kelly]<br />
|group=dev-platform<br />
|source_dirs=dom/workers/<br />
|url=https://developer.mozilla.org/En/Using_web_workers<br />
|components=Core::DOM: Workers<br />
}}<br />
<br />
{{Module<br />
|name=IndexedDB<br />
|description=<br />
|owner=[mailto:jvarga@mozilla.com Jan Varga]<br />
|peers=[mailto:btseng@mozilla.com Bevis Tseng], [mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:baku@mozilla.com Andrea Marchesini]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey]<br />
|group=dev-platform<br />
|source_dirs=dom/indexedDB/<br />
|url=https://developer.mozilla.org/en/IndexedDB<br />
|components=Core::DOM: IndexedDB<br />
}}<br />
<br />
{{Module<br />
|name=Editor<br />
|description=<br />
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-platform<br />
|source_dirs=editor/<br />
|url=http://www.mozilla.org/editor/<br />
|components=Core::Editor<br />
}}<br />
<br />
{{Module<br />
|name=Gecko Profiler<br />
|description=Gecko's built-in profiler<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|peers=[mailto:gsquelart@mozilla.com Gerald Squelart], [mailto:gtatum@mozilla.com Greg Tatum], [mailto:canaltinova@mozilla.com Nazim Can Altinova], [mailto:jseward@mozilla.com Julian Seward] (LUL), [mailto:kvijayan@mozilla.com Kannan Vijayan] (JS integration), [mailto:brennie@mozilla.com Barret Rennie] (Screenshots).<br />
|ownersemeritus=[mailto:b56girard@gmail.com Benoit Girard]<br />
|peersemeritus=[mailto:shu@mozilla.com Shu-yu Guo] (JS integration), [mailto:tlee@mozilla.com Thinker Lee] (TaskTracer), [mailto:cyu@mozilla.com Cervantes Yu] (TaskTracer), Nicholas Nethercote<br />
|group=dev-platform<br />
|source_dirs=tools/profiler/<br />
|url=https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler<br />
|components=Core::Gecko Profiler<br />
}}<br />
<br />
{{Module<br />
|name=Global Key Bindings<br />
|description=Global hot keys in Mozilla for the browser, editor, mail-news and widgets. Does not include underlined menu accelerators and the like, as those are part of i18n.<br />
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|group=dev-accessibility<br />
|source_dirs=dom/events (and platform specific directories under it)<br />
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html<br />
|components=Core::Keyboard: Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Graphics<br />
|description=Mozilla graphics API<br />
|owner=[mailto:jrmuizel@mozilla.com Jeff Muizelaar](Thebes, QCMS, YCbCr, Cairo/Pixman, Regions, OS X, Other)<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:bas.schouten@live.nl Bas Schouten](Layers, Windows), [mailto:jgilbert@mozilla.com Jeff Gilbert](WebGL, ANGLE), [mailto:mwoodrow@mozilla.com Matt Woodrow](Layers API), [mailto:jfkthame@googlemail.com Jonathan Kew](text/fonts), [mailto:nsilva@mozilla.com Nicolas Silva](MozSurface), [mailto:ncameron@mozilla.com Nick Cameron], [mailto:sikeda@mozilla.com Sotaro Ikeda](B2G), [mailto:jnicol@mozilla.com Jamie Nicol](Android), [mailto:snorp@mozilla.com James Willcox](Android), [mailto:mstange@themasta.com Markus Stange](OS X), [mailto:lsalzman@mozilla.com Lee Salzman](Skia, Canvas2D), [mailto:rhunt@mozilla.com Ryan Hunt](OMTP), [mailto:gwatson@mozilla.com Glenn Watson ](WebRender), [mailto:dmalyshau@mozilla.com Dzmitry Malyshau](WebRender)<br />
|peersemeritus=[mailto:bgirard@mozilla.com Benoit Girard](Compositor, Performance), [mailto:ajuma.bugzilla@alijuma.com Ali Juma], [mailto:george@mozilla.com George Wright](Canvas2D), [mailto:mchang@mozilla.com Mason Chang], [mailto:dvander@mozilla.com David Anderson], [mailto:clord@mozilla.com Christopher Lord], [mailto:jdaggett@mozilla.com John Daggett](text/fonts), [mailto:bjacob@mozilla.com Benoit Jacob](gfx/gl), [mailto:jdrew@mozilla.com Joe Drew], [mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=gfx/, dom/canvas/<br />
|url=https://wiki.mozilla.org/Platform/GFX https://wiki.mozilla.org/Gecko:Layers https://wiki.mozilla.org/Gecko:2DGraphicsSketch<br />
|components=Core::Graphics, Core::Graphics: Layers, Core::Graphics: Text, Core::Graphics: WebRender, Core::GFX: Color Management, Core::Canvas: 2D, Core::Canvas: WebGL<br />
}}<br />
<br />
{{Module<br />
|name=WebGPU (Graphics submodule)<br />
|description=WebGPU implementation<br />
|owner=[mailto:dmalyshau@mozilla.com Dzmitry Malyshau]<br />
|peers=[mailto:josh@joshgroves.com Joshua Groves], [mailto:jgilbert@mozilla.com Jeff Gilbert],<br />
|group=dev-platform<br />
|source_dirs=dom/webgpu<br />
|url=https://wiki.mozilla.org/Platform/GFX/WebGPU<br />
|components=Core::Graphics::WebGPU<br />
}}<br />
<br />
{{Module<br />
|name=APZ (Graphics submodule)<br />
|description=Asynchronous panning and zooming<br />
|owner=[mailto:bballo@mozilla.com Botond Ballo]<br />
|ownersemeritus=[mailto:kgupta@mozilla.staktrace.com Kartikaya Gupta]<br />
|peers=[mailto:kgupta@mozilla.staktrace.com Kartikaya Gupta], [mailto:tnikkel@mozilla.com Timothy Nikkel], [mailto:rhunt@mozilla.com Ryan Hunt], [mailto:mstange@mozilla.com Markus Stange]<br />
|group=dev-platform<br />
|source_dirs=gfx/layers/apz<br />
|url=https://wiki.mozilla.org/Platform/GFX/APZ<br />
|components=Core::Panning and Zooming<br />
}}<br />
<br />
{{Module<br />
|name=Moz2D (Graphics submodule)<br />
|description=Platform independent 2D graphics API<br />
|owner=[mailto:bschouten@mozilla.com Bas Schouten]<br />
|peers=[mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:gwright@mozilla.com George Wright], [mailto:jwatt@jwatt.org Jonathan Watt]<br />
|group=dev-platform<br />
|source=gfx/2d<br />
|url=https://wiki.mozilla.org/Platform/GFX/Moz2D<br />
|components=Core::Graphics<br />
}}<br />
<br />
{{Module<br />
|name=Legacy HTML Parser<br />
|description=<br />
|owner=[mailto:mrbkap@gmail.com Blake Kaplan]<br />
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:rbs@maths.uq.edu.au rbs@maths.uq.edu.au]<br />
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|source_dirs=parser/htmlparser<br />
|url=http://www.mozilla.org/newlayout/doc/parser.html<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=HAL<br />
|description=Hardware Abstraction Layer<br />
|owner=[mailto:gsvelto@mozilla.com Gabriele Svelto]<br />
|peers=<br />
|group=dev-platform<br />
|source_dirs=hal/<br />
|components=Core::Hardware Abstraction Layer (HAL)<br />
}}<br />
<br />
{{Module<br />
|name=HTML Parser<br />
|description=The HTML Parser transforms HTML source code into a DOM. It conforms to the HTML specification, and is mostly translated automatically from Java to C++.<br />
|owner=[mailto:hsivonen@iki.fi Henri Sivonen]<br />
|peers=[mailto:wchen@mozilla.com William Chen]<br />
|group=dev-platform<br />
|source_dirs=parser/html<br />
|url=http://about.validator.nu/<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=I18N Library<br />
|description=<br />
|owner=[mailto:hsivonen@hsivonen.fi Henri Sivonen (encoding)], [mailto:jfkthame@gmail.com Jonathan Kew (except to encoding)]<br />
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura], [mailto:gandalf@aviary.pl Zibi Braniecki], [mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]<br />
|ownersemeritus=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]<br />
|group=dev-i18n<br />
|source_dirs=intl/<br />
|url=http://mozilla.org/projects/intl/index.html<br />
|components=Core::Internationalization<br />
}}<br />
<br />
{{Module<br />
|name=ImageLib<br />
|description=<br />
|owner=[mailto:tnikkel@gmail.com Timothy Nikkel]<br />
|peers=[mailto:aosmond@mozilla.com Andrew Osmond], [mailto:jmuizelaar@mozilla.com Jeff Muizelaar]<br />
|peersemeritus=[mailto:seth.bugzilla@blackhail.net Seth Fowler], [mailto:netzen@gmail.com Brian Bondy], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-platform<br />
|source_dirs=media/libjpeg/, media/libpng/, image/, modules/zlib/<br />
|url=<br />
|components=Core::ImageLib<br />
}}<br />
<br />
{{Module<br />
|name=IPC<br />
|description=Native message-passing between threads and processes<br />
|owner=[mailto:jld@mozilla.com Jed Davis]<br />
|ownersemeritus=Chris Jones, Bill McCloskey<br />
|peers=[mailto:nika@thelayzells.com Nika Layzell], [mailto:jmathies@mozilla.com Jim Mathies], [mailto:amccreight@mozilla.com Andrew McCreight]<br />
|peersemeritus=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bent.mozilla@gmail.com Ben Turner], David Anderson, Kan-Ru Chen, Bevis Tseng, Ben Kelly<br />
|group=dev-platform<br />
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/<br />
|url=<br />
|components=Core::IPC}}<br />
<br />
{{Module<br />
|name=JavaScript<br />
|description=JavaScript engine (SpiderMonkey)<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:jdemooij@mozilla.com Jan de Mooij], André Bargull, [mailto:tcampbell@mozilla.com Ted Campbell], [mailto:jcoppeard@mozilla.com Jon Coppeard], [mailto:sphink@gmail.com Steve Fink], [mailto:arai.unmht@gmail.com Tooru Fujisawa], [mailto:evilpies@gmail.com Tom Schuster], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:jwalden@mit.edu Jeff Walden], [mailto:ystartsev@mozilla.com Yulia Startsev], [mailto:mgaudet@mozilla.com Matthew Gaudet], [mailto:iireland@mozilla.com Iain Ireland], [mailto:nicolas.b.pierron@mozilla.com Nicolas Pierron], [mailto:ccullen@mozilla.com Caroline Cullen], [mailto:nfitzgerald@mozilla.com Nick Fitzgerald], [mailto:luke@mozilla.com Luke Wagner], [mailto:sunfish@mozilla.com Dan Gohman], [mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peersemeritus=[mailto:brendan@mozilla.org Brendan Eich], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:nmatsakis@mozilla.com Niko Matsakis], [mailto:ejpbruel@mozilla.com Eddy Bruel], [mailto:danderson@mozilla.com David Anderson], [mailto:igor@mir2.org Igor Bukanov], Andreas Gal, [mailto:efaust@mozilla.com Eric Faust], [mailto:khyperia@mozilla.com Ashley Hauck], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:till@tillschneidereit.net Till Schneidereit], Nicholas Nethercote<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src<br />
|url=http://www.mozilla.org/js/spidermonkey,<br />
http://developer.mozilla.org/en/docs/About_JavaScript<br />
|components=Core::JavaScript Engine<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript JIT<br />
|description=JavaScript engine's JIT compilers (IonMonkey, Baseline)<br />
|owner=[mailto:jdemooij@mozilla.com Jan de Mooij]<br />
|peers=André Bargull, [mailto:bbouvier@mozilla.com Benjamin Bouvier], [mailto:tcampbell@mozilla.com Ted Campbell], [mailto:ccullen@mozilla.com Caroline Cullen], [mailto:mgaudet@mozilla.com Matthew Gaudet], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:iireland@mozilla.com Iain Ireland], [mailto:nicolas.b.pierron@mozilla.com Nicolas Pierron], [mailto:evilpies@gmail.com Tom Schuster], [mailto:sstangl@mozilla.com Sean Stangl], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:luke@mozilla.com Luke Wagner]<br />
|peersemeritus=[mailto:danderson@mozilla.com David Anderson], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:hv1989@gmail.com Hannes Verschore]<br />
|group=dev-tech-js-engine-internals<br />
|source_dirs=js/src/jit<br />
|url=http://www.mozilla.org/js/spidermonkey<br />
|components=Core::JavaScript Engine: JIT<br />
}}<br />
<br />
{{Module<br />
|name=jsat<br />
|description=Javascript screen reader that is used in Android and B2G<br />
|owner=[mailto:eitan@monotonous.org Eitan Isaacson]<br />
|peers=[mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|group=dev-accessibility<br />
|source_dirs=accessible/jsat/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=js-ctypes<br />
|description=A foreign function interface which allows privileged JS code to interact with binary code without using XPCOM/XPConnect.<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src/ctypes/<br />
|url=https://wiki.mozilla.org/JSctypes<br />
|components=Core::js-ctypes<br />
}}<br />
<br />
{{Module<br />
|name=js-tests<br />
|description=JavaScript test suite<br />
|owner=[mailto:bclary@bclary.com Bob Clary]<br />
|peers=<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tests/<br />
|url=http://www.mozilla.org/js/tests/library.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Layout Engine<br />
|description=rendering tree construction, layout (reflow), etc.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:jfkthame@gmail.com Jonathan Kew], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:matt.woodrow@gmail.com Matt Woodrow], [mailto:xidorn+moz@upsuper.org Xidorn Quan], [mailto:emilio@crisal.io Emilio Cobos Álvarez]<br />
|peersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/printing/, layout/tables/, layout/tools/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Layout<br />
|components=Core::Layout, Core::Layout: Block and Inline, Core::Layout: Columns, Core::Layout: Flexbox, Core::Layout: Floats, Core::Layout: Form Controls, Core::Layout: Generated Content, Lists, and Counters, Core::Layout: Grid, Core::Layout: Images, Video, and HTML Frames, Core::Layout: Positioned, Core::Layout: Ruby, Core::Layout: Scrolling and Overflow, Core::Layout: Tables, Core::Layout: Text and Fonts, Core::Print Preview, Core::Printing: Output<br />
}}<br />
<br />
{{Module<br />
|name=libjar<br />
|description=The JAR handling code (protocol handler, stream implementation, and zipreader/zipwriter).<br />
|owner=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|ownersemeritus=Taras Glek, Michael Wu<br />
|peers=[mailto:mnovotny@mozilla.com Michal Novotny], [mailto:vgosu@mozilla.com Valentin Gosu]<br />
|group=dev-platform<br />
|source_dirs=modules/libjar<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MathML<br />
|description=MathML is a low-level specification for describing mathematics which provides a foundation for the inclusion of mathematical expressions in Web pages.<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-tech-mathml<br />
|source_dirs=layout/mathml/<br />
|url=http://www.mozilla.org/projects/mathml/<br />
|components=Core::MathML<br />
}}<br />
<br />
{{Module<br />
|name=Media Playback<br />
|description=HTML Media APIs, including Media Source Extensions and non-MSE video/audio element playback, and Encrypted Media Extensions. (WebRTC and WebAudio not included).<br />
|owner=[mailto:jyavenard@mozilla.com Jean-Yves Avenard]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:cpearce@mozilla.com Chris Pearce]<br />
|peers=[mailto:kinetik@flim.org Matthew Gregan], [mailto:bvandyk@mozilla.com Bryce Van Dyk], [mailto:jolin@mozilla.com John Lin], [mailto:alwu@mozilla.com Alastor Wu], [mailto:jwwang@mozilla.com JW Wang]<br />
|group=dev-media<br />
|source_dirs=dom/media, media/gmp-clearkey/, media/libcubeb/, media/libnestegg/, media/libogg/, media/libopus/, media/libstagefright/, media/libtheora/, media/libtremor/, media/libvorbis/, media/libvpx/, media/omx-plugin/, media/rlz/<br />
|url=<br />
|components=Core::Audio/Video<br />
}}<br />
<br />
{{Module<br />
|name=Media Transport<br />
|description=Pluggable transport for real-time media<br />
|owner=[mailto:ekr@rtfm.com Eric Rescorla]<br />
|peers=[mailto:bcampen@mozilla.com Byron Campen], [mailto:abr@mozilla.com Adam Roach], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]<br />
|group=dev-media<br />
|source_dirs=media/mtransport<br />
|url=<br />
|components=Core::WebRTC::Networking<br />
}}<br />
<br />
{{Module<br />
|name=Memory Allocator<br />
|description=Most things related to memory allocation in Gecko, including jemalloc, replace-malloc, DMD (dark matter detector), logalloc, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=<br />
|peersemeritus=Eric Rahm, Nicholas Nethercote<br />
|group=dev-platform<br />
|source_dirs=memory/<br />
|components=Core::DMD, Core::jemalloc<br />
}}<br />
<br />
{{Module<br />
|name=mfbt<br />
|description=mfbt is a collection of headers, macros, data structures, methods, and other functionality available for use and reuse throughout all Mozilla code (including SpiderMonkey and Gecko more broadly).<br />
|owner=[mailto:jwalden@mit.edu Jeff Walden]<br />
|peers=[mailto:Ms2ger@gmail.com Ms2ger], [mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|group=dev-platform<br />
|source_dirs=mfbt/<br />
|url=<br />
|components=Core::MFBT<br />
}}<br />
<br />
{{Module<br />
|name=Mozglue<br />
|description=Glue library containing various low-level functionality, including a dynamic linker for Android, a DLL block list for Windows, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:kgupta@mozilla.com Kartikaya Gupta] (mozglue/android), [mailto:nchen@mozilla.com Jim Chen] (mozglue/android), [mailto:aklotz@mozilla.com Aaron Klotz] (Windows Dll Blocklist/Interceptor)<br />
|group=dev-platform<br />
|source_dirs=mozglue/<br />
|components=Core::mozglue<br />
}}<br />
<br />
{{Module<br />
|name=mozilla-toplevel<br />
|description=The top level directory for the mozilla tree.<br />
|owner=[[Modules/Firefox_Technical_Leadership|Firefox Technical Leadership module]]<br />
|ownersemeritus=[mailto:brendan@mozilla.org Brendan Eich]<br />
|peers=<br />
|group=<br />
|source_dirs=tools/README<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MSCOM<br />
|description=Integration with Microsoft Distributed COM<br />
|owner=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|peers=[mailto:jteh@mozilla.com James Teh], [mailto:jmathies@mozilla.com Jim Mathies]<br />
|group=dev-platform<br />
|source_dirs=ipc/mscom/%<br />
|url=<br />
|components=Core::IPC: MSCOM}}<br />
<br />
{{Module<br />
|name=Necko<br />
|description=The Mozilla Networking Library<br />
|owner=[mailto:dd.mozilla@gmail.com Dragana Damjanovic]<br />
|peers= [mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:mnovotny@mozilla.com Michal Novotny], [mailto:valentin.gosu@gmail.com Valentin Gosu], [mailto:kershaw@mozilla.com Kershaw Chang], [mailto:juhsu@mozilla.com Junior Hsu]<br />
|ownersemeritus=[mailto:mcmanus@ducksong.com Patrick McManus], [mailto:cbiesinger@gmail.com Christian Biesinger] |peersemeritus= Shih-Chiang Chien, [mailto:bzbarsky@mit.edu Boris Zbarsky], Steve Workman, Nick Hurley, [mailto:daniel@haxx.se Daniel Stenberg ], [mailto:jduell.mcbugs@gmail.com Jason Duell]<br />
|group=dev-tech-network<br />
|source_dirs=netwerk/%, netwerk/base/, netwerk/build/, netwerk/cache/, netwerk/dns/, netwerk/locales/, netwerk/mime/, netwerk/protocol/, netwerk/resources/, netwerk/socket/, netwerk/streamconv/, netwerk/system/, netwerk/test/, netwerk/testserver/<br />
|url=http://www.mozilla.org/projects/netlib/, https://developer.mozilla.org/en/Necko<br />
|components=Core::Networking, Core::Networking: Cache, Core::Networking: Cookies, Core::Networking: FTP, Core::Networking: File, Core::Networking: HTTP, Core::Networking: JAR, Core::Networking: Websockets<br />
}}<br />
<br />
{{Module<br />
|name=NodeJS usage, tools, and style<br />
|description=Advises on the use of NodeJS and npm packages at build and runtime. Reviews additions/upgrades/removals of vendored npm packages. Works with appropriate teams to maintain automated license and security audits of npm packages. Works with the security team and relevant developers to respond to vulnerabilities in NodeJS and vendored npm packages.<br />
|owner=[mailto:dmosedale@mozilla.com Dan Mosedale]<br />
|peers=[mailto:mbanner@mozilla.com Mark Banner], [mailto:dcoates@mozilla.com Danny Coates], [mailto:khudson@mozilla.com Kate Hudson], [mailto:jlaster@mozilla.com Jason Laster], [mailto:elee@mozilla.com Ed Lee], [mailto:dtownsend@mozilla.com Dave Townsend]<br />
|source_dirs=package.json, package-lock.json, node_modules and others as appropriate<br />
|components=Various components<br />
|forum=[https://wiki.mozilla.org/Firefox/firefox-dev firefox-dev], #nodejs on slack<br />
}}<br />
<br />
{{Module<br />
|name=NSPR<br />
|description=Netscape Portable Runtime<br />
|owner=[mailto:kaie@kuix.de Kai Engert]<br />
|peers=[mailto:mh@glandium.org Mike Hommey]<br />
|ownersemeritus=[mailto:wtc@google.com Wan-Teh Chang]<br />
|group=dev-tech-nspr<br />
|source_dirs=nsprpub/<br />
|url=http://www.mozilla.org/projects/nspr/<br />
http://www.mozilla.org/projects/nspr/reference/html/<br />
http://www.mozilla.org/projects/nspr/release-notes/<br />
|components=NSPR<br />
}}<br />
<br />
{{Module<br />
|name=PDF<br />
|description=Rendering code to display documents encoded in the ISO 32000-1 `PDF' format.<br />
|owner=[mailto:bdahl@mozilla.com Brendan Dahl]<br />
|peers=[mailto:aadib@mozilla.com Artur Adib], [mailto:vnicolas@mozilla.com Vivien Nicolas]<br />
|group=dev-platform<br />
|source_dirs=media/pdf/<br />
|url=https://github.com/mozilla/pdf.js<br />
|components=Core::PDF<br />
}}<br />
<br />
{{Module<br />
|name=Plugins<br />
|description= NPAPI Plugin support.<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:davidp99@gmail.com David Parks]<br />
|peersemeritus=[mailto:joshmoz@gmail.com Josh Aas], [mailto:john@pointysoftware.net John Schoenick], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:jstenback@gmail.com Johnny Stenback], Benjamin Smedberg<br />
|group=<br />
|source_dirs=dom/plugins/, modules/plugin/<br />
|url=https://wiki.mozilla.org/Plugins<br />
|components=Core::Plug-ins<br />
}}<br />
<br />
{{Module<br />
|name=Preferences<br />
|description=Preference library<br />
|owner=[mailto:kwright@mozilla.com Kristen Wright]<br />
|peers=[mailto:glandium@mozilla.com Mike Hommey], [mailto:kwright@mozilla.com Kristen Wright]<br />
|ownersemeritus=Nicholas Nethercote<br />
|peersemeritus=Felipe Gomes, Eric Rahm<br />
|group=dev-platform<br />
|source_dirs=modules/libpref/<br />
|url=<br />
|components=Core::Preferences: Backend<br />
}}<br />
<br />
{{Module<br />
|name=Private Browsing<br />
|description=Implementation of the Private Browsing mode, and the integration of other modules with Private Browsing APIs.<br />
|owner=[mailto:eakhgari@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:josh@joshmatthews.net Josh Matthews]<br />
|group=dev-platform<br />
|source_dirs=Implementation and consumers of Private Browsing APIs in nsILoadContext, nsIPrivateBrowsingChannel, PrivateBrowsingUtils.jsm and the related glue code. <br />
|url=https://wiki.mozilla.org/Private_Browsing<br />
|components=Firefox::Private Browsing<br />
}}<br />
<br />
{{Module<br />
|name=Privilege Manager<br />
|description="caps"<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]<br />
|peersemeritus=[mailto:brendan@mozilla.org Brendan Eich], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:dveditz@mozilla.com Dan Veditz]<br />
|group=dev-tech-dom<br />
|source_dirs=caps/<br />
|url=http://www.mozilla.org/projects/security/components/index.html<br />
|components=Core::Security: CAPS<br />
}}<br />
<br />
{{Module<br />
|name=Push Notifications<br />
|description=Push is a way for application developers to send messages to their web applications.<br />
|owners=[mailto:lina@mozilla.com Lina Cambridge]<br />
|ownersemeritus=[mailto:doug.turner@gmail.com Doug Turner]<br />
|peers=[mailto:mt@lowentropy.net Martin Thomson], [mailto:ddamjanovic@mozilla.com Dragana Damjanovic]<br />
|peersemeritus=[mailto:nsm.nikhil@gmail.com Nikhil Marathe]<br />
|group=<br />
|source_dirs=dom/push<br />
|url=<br />
|components=Core::DOM: Push Notifications<br />
}}<br />
<br />
{{Module<br />
|name=security<br />
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)<br />
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:mt@lowentropy.net Martin Thomson]<br />
|ownersemeritus=[mailto:wtc@google.com Wan-Teh Chang], [mailto:ttaubert@mozilla.com Tim Taubert]<br />
|peers=[mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi], [mailto:ekr@rtfm.com Eric Rescorla], [mailto:franziskuskiefer@gmail.com Franziskus Kiefer], [mailto:dueno@redhat.com Daiki Ueno]<br />
|peersemeritus=[mailto:emaldona@redhat.com Elio Maldonado]<br />
|group=dev-tech-crypto<br />
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/<br />
|url=http://mozilla.org/projects/security/pki/<br />
|components=NSS, JSS, Core::Security, Core::Security: S/MIME<br />
}}<br />
<br />
{{Module<br />
|name=Security - Mozilla PSM Glue<br />
|description=Personal Security Manager<br />
|owner=[mailto:dkeeler@mozilla.com Dana Keeler]<br />
|ownersemeritus=[mailto:kaie@kuix.de Kai Engert (2001-2012)]<br />
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:cykesiopka.bmo@gmail.com Cykesiopka], [mailto:jc@mozilla.com J.C. Jones], [mailto:fkiefer@mozilla.com Franziskus Kiefer]<br />
|group=dev-tech-crypto<br />
|source_dirs=security/manager/<br />
|url=<br />
|components=Core::Security: PSM<br />
}}<br />
<br />
{{Module<br />
|name=Static analysis & rewriting for C++<br />
|description=Tools for checking C++ code looking for problems at compile time, plus tools for automated rewriting of C++ code.<br />
|owner=[mailto:andi@mozilla.com Andi-Bogdan Postelnicu]<br />
|peers=[mailto:nika@thelayzells.com Nika Layzell], [mailto:sfink@mozilla.com Steve Fink], [mailto:jrmuizel@mozilla.com Jeff Muizelaar], [mailto:eakhgari@mozilla.com Ehsan Akhgari]<br />
|peersemeritus=[mailto:birunthan@mohanathas.com Birunthan Mohanathas]<br />
|group=dev-platform<br />
|source_dirs=build/clang-plugin, tools/rewriting among other out of tree tools<br />
|url=<br />
|components=Core::Rewriting & Analysis<br />
}}<br />
{{Module<br />
|name=storage<br />
|description=Storage APIs with a SQLite backend<br />
|owner=[mailto:mak77@bonardo.net Marco Bonardo]<br />
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:jvarga@mozilla.com Jan Varga]<br />
|group=dev-platform<br />
|source_dirs=db/sqlite3/, storage/<br />
|url=http://developer.mozilla.org/en/docs/Storage<br />
|components=Toolkit::Storage, Core::SQL<br />
}}<br />
<br />
{{Module<br />
|name=String<br />
|description=<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-tech-xpcom<br />
|source_dirs=string/, xpcom/string/<br />
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide<br />
|components=Core::String<br />
}}<br />
<br />
{{Module<br />
|name=Style System<br />
|description=CSS style sheet handling; style data computation<br />
|owner=[mailto:cam@mcc.id.au Cameron McCormack]<br />
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:emilio@crisal.io Emilio Cobos Álvarez], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:xidorn+moz@upsuper.org Xidorn Quan], [mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/style/, servo/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System<br />
|components=Core::CSS Parsing and Computation<br />
}}<br />
<br />
{{Module<br />
|name=SVG<br />
|description=Scalable Vector Graphics<br />
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]<br />
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]<br />
|group=dev-tech-svg<br />
|source_dirs=dom/svg/, layout/svg/, dom/smil/<br />
|url=https://developer.mozilla.org/en-US/docs/Web/SVG<br />
|components=Core::SVG<br />
}}<br />
<br />
{{Module<br />
|name=View System<br />
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]<br />
|group=dev-tech-layout<br />
|source_dirs=view/<br />
|url=<br />
|components=Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=Web Audio<br />
|description=Support for the W3C Web Audio API specification.<br />
|owner=[mailto:padenot@mozilla.com Paul Adenot]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:karlt+@karlt.net Karl Tomlinson]<br />
|group=dev-platform<br />
|source_dirs=dom/media/webaudio<br />
|url=https://wiki.mozilla.org/Web_Audio_API<br />
|components=Core::Web Audio<br />
}}<br />
<br />
{{Module<br />
|name=Web Painting<br />
|description=painting, display lists, and layer construction<br />
|owner=[mailto:matt.woodrow@gmail.com Matt Woodrow]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dbaron@dbaron.org David Baron], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:mstange@themasta.com Markus Stange], [mailto:mmynttinen@mozilla.com Miko Mynttinen], [mailto:jnicol@mozilla.com Jamie Nicol]<br />
|group=dev-tech-layout<br />
|source_dirs= layout/painting, the display list and layer related methods on nsIFrame and its subclasses<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|components=Core::Layout: Web Painting<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC<br />
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=netwerk/sctp (also see submodules "WebRTC Media" and "WebRTC Signaling")<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC, Core::WebRTC Networking<br />
}}<br />
<br />
{{Module<br />
|name=WebVR<br />
|description=Gecko's implementation of WebVR (Virtual Reality) functionality, including API, devices, graphics and integration<br />
|owner=[mailto:kgilbert@mozilla.com Kearwood (Kip) Gilbert]<br />
|peers=[mailto:dmu@mozilla.com Daosheng Mu], [mailto:igorostizaga@mozilla.com Imanol Fernández]<br />
|peersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=dom/vr, gfx/vr<br />
|url=https://mozvr.com/<br />
|components=Core::WebVR<br />
}}<br />
<br />
{{Module<br />
|name=Widget<br />
|description=Top level Widget<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|ownersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peersemeritus=[mailto:pavlov@pavlov.net Stuart Parmenter], <br />
|group=dev-platform<br />
|source_dirs=widget/, widget/xpwidgets/<br />
|url=<br />
|components=Core::Drag and Drop, Core::Widget, Core::Printing: Setup<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Android<br />
|description=Android widget support<br />
|owner=[mailto:jwillcox@mozilla.com James Willcox]<br />
|peers=<br />
|ownersemeritus=[mailto:blassey.bugs@lassey.us Brad Lassey]<br />
|group=dev-platforms-mobile<br />
|source_dirs=widget/android/, embedding/android<br />
|url=<br />
|components=Core::Widget: Android<br />
}}<br />
<br />
{{Module<br />
|name=Widget - GTK<br />
|description=GTK widget support<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:stransky@redhat.com Martin Stránský]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-platform<br />
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/<br />
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/<br />
|components=Core::Widget: Gtk<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Headless<br />
|description=Headless widget support<br />
|owner=[mailto:bdahl@mozilla.com Brendan Dahl]<br />
|peers=<br />
|ownersemeritus=<br />
|group=dev-platform<br />
|source_dirs=widget/headless/<br />
|url=<br />
|components=Firefox::Headless<br />
}}<br />
<br />
{{Module<br />
|name=Widget - macOS<br />
|description= macOS widget support<br />
|owner=[mailto:spohl@mozilla.com Stephen A Pohl]<br />
|peers=[mailto:mstange@themasta.com Markus Stange], [mailto:haftandilian@mozilla.com Haik Aftandilian]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:mstange@themasta.com Markus Stange]<br />
|peersemeritus=[mailto:joshmoz@gmail.com Josh Aas], [mailto:b56girard@gmail.com Benoit Girard], [mailto:smichaud@pobox.com Steven Michaud]<br />
|group=dev-platform<br />
|source_dirs=widget/cocoa/<br />
|url=<br />
|components=Core::Widget: Cocoa<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Windows<br />
|description=Windows widget support<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:cmartin@mozilla.com Chris Martin], [mailto:tkikuchi@mozilla.com Toshihito Kikuchi], [mailto:mhowell@mozilla.com Molly Howell], [mailto:aklotz@mozilla.com Aaron Klotz], [mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|peersemeritus=[mailto:robert.strong.bugs@gmail.com Rob Strong], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:doug.turner@gmail.com Doug Turner], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:robarnold@cmu.edu Rob Arnold]<br />
|group=dev-platform<br />
|source_dirs=widget/windows/<br />
|url=<br />
|components=Core::Widget: Win32<br />
}}<br />
<br />
{{Module<br />
|name=XML<br />
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-xml<br />
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/<br />
|url=http://www.mozilla.org/newlayout/xml/<br />
|components=Core::XML<br />
}}<br />
<br />
{{Module<br />
|name=XPApps<br />
|description=Cross-Platform Applications, mostly Navigator front end and application shell.<br />
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-apps-seamonkey<br />
|source_dirs=xpfe/<br />
|url=http://www.mozilla.org/xpapps/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPCOM<br />
|description=The cross-platform object model and core data structures.<br />
|owner=[mailto:nika@thelayzells.com Nika Layzell]<br />
|peers=[mailto:erahm@mozilla.com Eric Rahm], [mailto:kmaglione@mozilla.com Kris Maglione], [mailto:sgiesecke@mozilla.com Simon Giesecke]<br />
|ownersemeritus=Benjamin Smedberg<br />
|peersemeritus=[https://mozillians.org/en-US/u/dougt/ Doug Turner]<br />
|group=dev-platform<br />
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/<br />
|url=http://developer.mozilla.org/en/XPCOM<br />
|components=Core::XPCOM<br />
}}<br />
<br />
{{Module<br />
|name=XPConnect<br />
|description=Deep Magic<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:kmaglione@mozilla.com Kris Maglione], [mailto:nika@thelayzells.com Nika Layzell]<br />
|peersemeritus=[mailto:gal@uci.edu Andreas Gal], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]<br />
|group=<br />
|source_dirs=js/xpconnect/<br />
|url=<br />
|components=Core::XPConnect<br />
}}<br />
<br />
{{Module<br />
|name=XPIDL<br />
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.<br />
|owner=[mailto:nika@thelayzells.com Nika Layzell]<br />
|peers=[mailto:amccreight@mozilla.com Andrew McCreight]<br />
|ownersemeritus=[mailto:me@kylehuey.com Kyle Huey]<br />
|peersemeritus=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-tech-xpcom<br />
|source_dirs=xpcom/typelib/<br />
|url=http://www.mozilla.org/scriptable/xpidl<br />
http://www.mozilla.org/scriptable<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XSLT Processor<br />
|description=XSLT transformations processor<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:axel@pike.org Axel Hecht]<br />
|group=dev-tech-xslt<br />
|source_dirs=dom/xslt/<br />
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html<br />
|components=Core::XSLT<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Windows <br />
|description=Sandboxing for the Windows platform <br />
|owner=[mailto:bobowencode@gmail.com Bob Owen] (:bobowen)<br />
|peers=[mailto:aklotz@mozilla.com Aaron Klotz] (:aklotz), [mailto:jimm@mozilla.com Jim Mathies] (:jimm), [mailto:davidp99@gmail.com David Parks] (:handyman)<br />
|ownersemeritus=[https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes]<br />
|peersemeritus=[mailto:netzen@gmail.com Brian Bondy]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/win <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - OSX <br />
|description=Sandboxing for the OSX platform <br />
|owner=[mailto:haftandilian@mozilla.com Haik Aftandilian]<br />
|peers=<br />
|group=dev-platform <br />
|source_dirs=security/sandbox/mac <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Linux<br />
|description=Sandboxing for the Linux platform<br />
|owner=[mailto:jld@mozilla.com Jed Davis]<br />
|peers=[mailto:gcp@mozilla.com Gian-Carlo Pascutto]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/linux<br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Crash reporting<br />
|description=Infrastructure and tools used to generate, submit and process crash reports. This includes the in-tree google-breakpad fork, the crash report generation machinery as well as the host tools used to dump symbols, analyse minidumps and generate stack traces.<br />
|owner=[mailto:gsvelto@mozilla.com Gabriele Svelto] (:gsvelto)<br />
|peers=<br />
|group=dev-platform<br />
|source_dirs=toolkit/crashreporter, toolkit/components/crashes, tools/crashreporter, ipc/glue/CrashReporter*, mobile/android/geckoview/src/main/java/org/mozilla/geckoview/CrashReporter.java<br />
|url=https://firefox-source-docs.mozilla.org/toolkit/crashreporter/crashreporter/index.html<br />
|components=Toolkit::Crash Reporting<br />
}}<br />
<br />
===Submodules===<br />
{{Module<br />
|name=Build Config - Fennec<br />
|description=Submodule of the build config covering Fennec's build system in mobile/android.<br />
|owner=[mailto:nalexander@mozilla.com Nicholas Alexander]<br />
|peers=Same as Build Config<br />
|group=dev-builds<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Build Config - Taskgraph<br />
|description=Support for task-graph generation in decision, action, and cron tasks, including configuration of all tasks including those for CI, nightlies, and releases; as well as Docker and VM images used to execute those tasks.<br />
|owner=[mailto:mozilla@hocat.ca Tom Prince]<br />
|peers=[mailto:ahal@mozilla.com Andrew Halberstadt], [mailto:aki@mozilla.com Aki Sasaki], [mailto:bstack@mozilla.com Brian Stack], [mailto:mh@glandium.org Mike Hommey], [mailto:gps@mozilla.com Gregory Szorc], [mailto:jmaher@mozilla.com Joel Maher], [mailto:callek@mozilla.com Justin Wood], [mailto:dustin@mozilla.com Dustin Mitchell]<br />
|components=Firefox Build System::Task Configuration<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Media<br />
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:jib@mozilla.com Jan-Ivar Bruaroey], [mailto:dminor@mozilla.com Dan Minor], [mailto:apehrson@mozilla.com Andreas Pehrson], <br />
|peersemeritus=[mailto:pkerr@mozilla.com Paul Kerr], [mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc, /dom/media/webrtc, /dom/media/systemservices<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Audio/Video)<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Signaling<br />
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling<br />
|owner=[mailto:bcampen@mozilla.com Byron Campen]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:abr@mozilla.com Adam Roach], [mailto:rjesup@mozilla.com Randell Jesup], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc/signaling/<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Signaling)<br />
}}<br />
<br />
<noinclude><br />
<br />
===Unassigned Bugzilla Components===<br />
<br />
The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):<br />
<br />
<pre><br />
Core::Find Backend<br />
Core::General<br />
Core::History: Global<br />
Core::Image Blocking<br />
Core::Localization<br />
Core::Networking: Domain Lists<br />
Core::Selection<br />
Core::Serializers<br />
Core::Spelling checker<br />
Core::X-remote<br />
Core::XUL<br />
</pre><br />
</noinclude></div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Low_Level_Tools&diff=1231138Low Level Tools2020-09-29T05:43:45Z<p>Nnethercote: </p>
<hr />
<div><big>'''''The Low Level Tools team was merged into the OS integration team in September 2020. This page remains for historical purposes.'''''</big><br />
<br />
=Low Level Tools=<br />
The Low Level Tools team is a geographically distributed team that works on a variety of projects ranging from compiler work, build systems, debugger integration, performance improvements, crash reporting, memory management and usage, and general code cleanliness.<br />
<br />
== Team ==<br />
<br />
Most of us can be found in the [irc://irc.mozilla.org/memshrink #memshrink] and [irc://irc.mozilla.org/rustc #rustc] channels on irc.mozilla.org.<br />
<br />
* Nathan Froyd :froydnj<br />
* Mike Hommey :glandium<br />
* Nicholas Nethercote :njn<br />
* Eric Rahm :erahm<br />
* Gabriele Svelto :gsvelto<br />
* Michael Woerister :mw<br />
* Kristen Wright :kriswright<br />
* dmajor<br />
<br />
== Current Projects ==<br />
<br />
* [[Project Fission/Memory]]<br />
* [https://github.com/rust-lang/rust/issues/48168 Rust lldb integration]<br />
* [https://github.com/rust-lang/rust/issues/47660 Rust Thin LTO]<br />
* rustc performance<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1515668 Windows on ARM64 support]<br />
* Crash Reporting<br />
* [[Performance/MemShrink]]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=752004 clang-cl (building with clang on windows)]<br />
<br />
== Status ==<br />
<br />
Weekly status reports<br />
* [[Low Level Tools/Status2019Q1|2019Q1]]<br />
* [[Low Level Tools/Status2018Q4|2018Q4]]<br />
<br />
== Goals ==<br />
<br />
Half-Year Goals<br />
* [[Low Level Tools/2019H1|2019H1]]<br />
* [[Low Level Tools/2018H2|2018H2]]<br />
<br />
Quarterly goals<br />
* [[Low Level Tools/2019Q2|2019Q2]]<br />
* [[Low Level Tools/2019Q1|2019Q1]]<br />
* [[Low Level Tools/2018Q4|2018Q4]]<br />
* [[Low Level Tools/2018Q3|2018Q3]]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Performance/Project_Candle&diff=1230539Performance/Project Candle2020-09-02T07:21:02Z<p>Nnethercote: </p>
<hr />
<div>'''''Project Candle ran from 2015-2016.'''''<br />
<br />
Project Candle aims to reduce the power consumption of Firefox (on desktop and mobile) and Firefox OS, in order to increase battery life for users on mobile devices. Some reductions in power consumption will also help improve performance, such as those that reduce CPU usage.<br />
<br />
Project Candle is a Platform Engineering initiative that aims to extend and complement existing work relating to power consumption within Mozilla.<br />
<br />
== Mailing list ==<br />
<br />
'''''The mailing list still exists, but in practice nobody is posting to it for now.'''''<br />
<br />
The Project Candle mailing list is called [https://lists.mozilla.org/listinfo/dev-power dev-power].<br />
<br />
Instead of having regular face-to-face meetings, this list will serve as the central point of contact for all discussions and bug triaging for Project Candle. While having no face-to-face meetings does reduce the immediacy of discussion, we hope this will be outweighed by other advantages.<br />
<br />
First, given that the reduction of power consumption potentially requires people with expertise in many parts of the codebase, it is important to avoid excluding anybody. A mailing list achieves this in the following ways.<br />
<br />
* Nobody needs to miss discussion due to being permanently in a particular timezone.<br />
* Nobody needs to miss discussion due to being temporarily unavailable at a particular time.<br />
* It's easy to "lurk", i.e. follow along in a low-commitment fashion.<br />
<br />
Second, there are some practical benefits.<br />
<br />
* All discussions are permanently archived.<br />
* Fewer meetings for everybody.<br />
<br />
If you are interested in helping or even just following progress, joining the mailing list is the single best thing you can do.<br />
<br />
== IRC ==<br />
<br />
The #power channel is for discussions relating to power consumption.<br />
<br />
== Bug tracking ==<br />
<br />
'''''Triage threads are not being performed at the moment, and "[Power]" whiteboard annotations are currently not being used.'''''<br />
<br />
Bugs are prioritized via periodic triage threads on the mailing list. The process is described in the section below.<br />
<br />
If you want a bug that is related to power usage to be triaged on the mailing list, add "[Power]" to the bug whiteboard. After prioritization, this whiteboard marking will be changed to one of "[Power:P1]", "[Power:P2]", "[Power:P3]" or "[Power:meta]". The meaning of these markings, and links to all such bugs, is as follows. <br />
<br />
* [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=regexp&query_format=advanced&list_id=577353&status_whiteboard=%5C%5BPower%5C%5D&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&resolution=---&resolution=DUPLICATE Unprioritized Power bugs]. These are prioritized regularly on the mailing list.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?list_id=463753&resolution=---&resolution=DUPLICATE&status_whiteboard_type=regexp&query_format=advanced&status_whiteboard=%5C%5BPower%3AP1%5C%5D&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&order=bugs.bug_id Power:P1 bugs]. Once prioritized, these will be revisited and discussed occasionally on the mailing list. We will try to keep the number of such bugs small and constant, e.g. a dozen or so.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?list_id=463753&resolution=---&resolution=DUPLICATE&status_whiteboard_type=regexp&query_format=advanced&status_whiteboard=%5C%5BPower%3AP2%5C%5D&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&order=bugs.bug_id Power:P2 bugs]. Once prioritized, these will be revisited and discussed rarely on the mailing list. P2 is the default priority, and should be used when a bug is not obviously important or unimportant.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?list_id=463753&resolution=---&resolution=DUPLICATE&status_whiteboard_type=regexp&query_format=advanced&status_whiteboard=%5C%5BPower%3AP3%5C%5D&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&order=bugs.bug_id Power:P3 bugs]. Once prioritized, these are unlikely to be revisited and discussed again on the mailing list.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?list_id=463753&resolution=---&resolution=DUPLICATE&status_whiteboard_type=regexp&query_format=advanced&status_whiteboard=%5C%5BPower%3Ameta%5C%5D&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&order=bugs.bug_id Power:meta bugs]. Once prioritized, these will be revisited and discussed occasionally on the mailing list.<br />
<br />
Some other interesting bug lists that overlap with the ones above.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?list_id=463753&resolution=---&resolution=DUPLICATE&status_whiteboard_type=regexp&query_format=advanced&status_whiteboard=%5C%5BPower&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&order=bugs.bug_id All Power bugs].<br />
* [https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=regexp&query_format=advanced&list_id=1252875&status_whiteboard=%5C%5BPower&bug_status=UNCONFIRMED&resolution=---&resolution=DUPLICATE Unconfirmed Power bugs]. These are problems reported by users and generally require some kind of additional work to confirm.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?f1=bug_mentor&list_id=12543430&o1=isnotempty&resolution=---&resolution=DUPLICATE&status_whiteboard_type=regexp&query_format=advanced&status_whiteboard=%5C%5BPower&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED Power bugs with a "mentor" annotation]. These are bugs that someone has identified as reasonable easy, and that person is willing to help a newcomer fix the bug.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?list_id=1252950&resolution=---&resolution=DUPLICATE&emailtype1=regexp&status_whiteboard_type=regexp&emailassigned_to1=1&query_format=advanced&status_whiteboard=%5C%5BPower&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=nobody%40%7Cgeneral%40js.bugs Unassigned Power bugs]. These need someone to work on them.<br />
<br />
There is also a "power" keyword in Bugzilla, but this won't be used by Project Candle because the whiteboard annotations described above are more flexible.<br />
<br />
== Bug triage process ==<br />
<br />
'''''The email-based triage process turned out to be flawed. The responsibility, borne by a single person, to write something substantive for every nominated bug was onerous. Synchronous meetings will likely be more effective.'''''<br />
<br />
These threads will have a title such as "Project Candle bug triage (7th September 2015)". The triage manager will initiate these threads, listing each bug, asking relevant questions, and suggesting priorities.<br />
<br />
The primary purpose of these threads is to get eyes on bugs that have been marked with the "[Power]" whiteboard marking and to triage them. If we can also find people to do further investigation and/or assign themselves to a bug, even better, though that is not expected to happen with every bug.<br />
<br />
So please take a few minutes to look through the listed bugs. For each bug, decide if you agree with the suggested priority, and consider if you can add to the discussion in the bug, suggest somebody who might be able to work on it, or even take it on yourself.<br />
<br />
Note also that these email threads are substituting for face-to-face meetings where basic agreement can be achieved quickly and obviously. In contrast, on mailing lists it is harder to reach agreement like this, particularly because the bar for response is higher and it is traditional to avoid responding with simple "I agree" messages. Nonetheless, for these triage threads we specifically encourage this kind of response. In particular, if you agree with all the suggestions a simple "+1" response is helpful. Without such responses, it is likely that there will be few responses and the triage manager -- who took the time to write the message that starts the thread -- won't know if it's because (a) everybody agrees with their suggestions, or (b) nobody looked at the bugs, or (c) nobody cares. This lack of information is discouraging.<br />
<br />
A few days later, after discussion has occurred, the triage manager will update the bugs appropriately.<br />
<br />
== Documentation and Tools ==<br />
<br />
The "Power profiling" section of the [https://developer.mozilla.org/en-US/docs/Mozilla/Performance MDN performance page] has a link to a [https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Power_profiling_overview power profiling overview] document that introduces many concepts relevant to power profiling. That section also has links to a number of other documents that describe tools that can be used for power profiling.<br />
<br />
MicroSoft [https://blogs.windows.com/msedgedev/2016/06/20/edge-battery-anniversary-update/ wrote] about how they improved the power consumption of Edge.<br />
<br />
== Progress tracking ==<br />
<br />
We will need to set up some kind of automated system for tracking power consumption. This will let us measure progress and also detect regressions.<br />
<br />
There are several open questions relating to this.<br />
<br />
* Which platforms? (Note that dedicated hardware is best for power consumption measurement, because a lot of the tools do system-wide measurements.)<br />
* Which other browsers do we compare with?<br />
* Which metrics do we use?<br />
* What workloads do we test?<br />
<br />
For Firefox, Roberto Vitillo's [https://github.com/mozilla/energia Energia] [http://people.mozilla.org/~rvitillo/dashboard/ dashboard] may serve as a good starting point. (Note that this dashboard has not been updated in over a year and so its actual data should be ignored at this time.)<br />
<br />
For Firefox OS there are already current measurements being made and fed into [http://raptor.mozilla.org/#/dashboard/script/current.js?device=flame-kk&branch=master&memory=1024 Raptor].</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Modules/Core&diff=1229532Modules/Core2020-07-28T00:35:26Z<p>Nnethercote: </p>
<hr />
<div><noinclude><br />
'''Only module owners may edit this page.''' <br />
<br />
They may:<br />
<br />
* update any information about their module except the name of the owner<br />
* add or remove sub-modules<br />
* change the owner of a sub-module <br />
* add emeritus owners or peers<br />
<br />
Other changes, including changes of module owner or addition/removal of modules, must be agreed with the Module Ownership Module group, probably via a discussion in [https://www.mozilla.org/about/forums/#governance mozilla.governance].<br />
</noinclude><br />
{{Module<br />
|name=Accessibility<br />
|description=Support for platform accessibility APIs. Accessibility APIs are used by 3rd party software like screen readers, screen magnifiers, and voice dictation software, which need information about document content and UI controls, as well as important events like changes of focus.<br />
|owner=[mailto:jteh@mozilla.com Jamie Teh]<br />
|peers=[mailto:eitan@monotonous.org Eitan Isaacson], [mailto:jteh@mozilla.com James Teh], [mailto:mzehe@mozilla.com Marco Zehe], [mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|ownersemeritus=[mailto:aaron@moonset.net. Aaron Leventhal], [mailto:surkov.alexander@gmail.com Alexander Surkov]<br />
|peersemeritus=[mailto:dbolter@mozilla.com David Bolter], [mailto:tbsaunde+mozbugs@tbsaunde.org Trevor Saunders], [mailto:ginn.chen@oracle.com Ginn Chen], Evan Yan<br />
|group=dev-accessibility<br />
|source_dirs=accessible/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=Animation<br />
|description=Declarative animations: CSS animations, CSS transitions, Web Animations API, and off-main thread animations.<br />
|owner=[mailto:brian@birchill.co.jp Brian Birtles] (:birtles)<br />
|peers=[mailto:boris@mozilla.com Boris Chiou] (:boris), [mailto:hikezoe.birchill@mozilla.com Hiroyuki Ikezoe] (:hiro), [mailto:mwoodrow@mozilla.com Matt Woodrow] (:mattwoodrow)<br />
|group=dev-tech-layout<br />
|source_dirs=dom/animation; and animation-related and interpolation-related code in layout/style, gfx/layers, servo/components/style and servo/ports/gecko<br />
|components=Core::DOM::Animation, Core::CSS Transitions and Animations<br />
}}<br />
<br />
{{Module<br />
|name=Anti-Tracking<br />
|description=Tracking detection and content-blocking.<br />
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]<br />
|peers=[mailto:dlee@mozilla.com Dimi Lee], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:ewright@mozilla.com Erica Wright], [mailto:xeonchen@gmail.com Gary Chen], [mailto:jhofmann@mozilla.com Johann Hofmann], [mailto:tihuang@mozilla.com Tim Huang]<br />
|group=dev-platform<br />
|source_dirs=toolkit/components/antitracking/, several files under browser/ and netwerk/url-classifier/<br />
|components=Core::Privacy: Anti-Tracking<br />
}}<br />
<br />
{{Module<br />
|name=Browser WebAPI<br />
|description=Web API for rendering apps, browser windows and widgets.<br />
|owner=[mailto:Olli.Pettay@helsinki.fi Olli Pettay]<br />
|peers=[mailto:fabrice@mozilla.com Fabrice Desré]<br />
|ownersemeritus=[mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|group=dev-webapi<br />
|source_dirs=dom/browser-element/<br />
|url=<br />
|components=Core::DOM<br />
}}<br />
<br />
{{Module<br />
|name=Build and Release Tools<br />
|description=Tools related to build and release automation and configuration of release builds.<br />
|owner=[mailto:nthomas@mozilla.com Nick Thomas]<br />
|peers=[mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:coop@mozilla.com Chris Cooper]<br />
|group=release-engineering<br />
|source_dirs=browser/config/mozconfigs/, mobile/android/config/mozconfigs/, xulrunner/config/mozconfigs/, b2g/config/, tools/update-packaging/<br />
|url=https://wiki.mozilla.org/ReleaseEngineering<br />
|components=Release Engineering::*<br />
}}<br />
<br />
{{Module<br />
|name=Build Config<br />
|description=The build system for Gecko and several mozilla.org hosted Gecko-based applications.<br />
|owner=[mailto:mh@glandium.org Mike Hommey] (:glandium)<br />
|peers=[mailto:mshal@mozilla.com Mike Shal] (:mshal), [mailto:nfroyd@mozilla.com Nathan Froyd] (:froydnj), [mailto:dmajor@mozilla.com David Major] (:dmajor), [mailto:rstewart@mozilla.com Ricky Stewart] (:ricky)<br />
|ownersemeritus=Chris Manchester (2019-2020), Gregory Szorc (2013-2019), Ted Mielczarek (2008-[https://blog.mozilla.org/ted/2013/03/07/gregory-szorc-is-now-the-build-config-module-owner/ 2013]), Benjamin Smedberg (???-[http://benjamin.smedbergs.us/blog/2008-04-30/more-changing-of-the-guard-ted-mielczarek/ 2008]), <br />
|peersemeritus=Ted Mielczarek, Ralph Giles, Gregory Szorc, Chris Manchester<br />
|group=dev-builds<br />
|source_dirs=build/, config/, python/mozbuild, tools/cross-commit, tools/cvs2hg-import.py, tools/cvsmgmt/, tools/elf-dynstr-gc/, tools/trees.pl, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/<br />
|url=http://www.mozilla.org/build/<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Code Analysis and Debugging Tools<br />
|description=Tools for debugging Mozilla code or for analyzing speed, memory use, and other characteristics of it.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=<br />
|group=dev-performance<br />
|source_dirs=tools/codesighs/, tools/debug/, tools/dreftool/, tools/dumpdeps/, tools/jprof/, tools/leak-gauge/, tools/leaky/, tools/memory/, tools/module-deps/, tools/performance/, tools/post_compile/, tools/preloader/, tools/rb/, tools/reorder/, tools/trace-malloc/, tools/uuiddeps/, <br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Content Security<br />
|description=Native content-based security features enforced in the ContentSecurityManager, including: Content Security Policy (CSP), Mixed Content Blocker (MCB), Referrer Policy, Subresource Integrity (SRI), Cross-Origin Resource Sharing (CORS) and top-level data: URI blocking.<br />
|owner=[mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]<br />
|peers=[mailto:tvyas@mozilla.com Tanvi Vyas], [mailto:dveditz@mozilla.com Dan Veditz], [mailto:amarchesini@mozilla.com Andrea Marchesini], [mailto:jkt@mozilla.com Jonathan Kingston], [mailto:tnguyen@mozilla.com Thomas Nguyen]<br />
|peersemeritus=[mailto:mozilla@sidstamm.com Sid Stamm], [mailto:jonas@sicking.cc Jonas Sicking], François Marier<br />
|group=dev-security<br />
|source_dirs=dom/security<br />
|components=Core::DOM: Security<br />
}}<br />
<br />
{{Module<br />
|name=Cookies<br />
|description=<br />
|owner=[mailto:amarchesini@mozilla.com Andrea Marchesini]<br />
|peers=[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:honzab.moz@firemni.cz Honza Bambas] <br />
|ownersemeritus=Monica Chew<br />
|peersemeritus=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]<br />
|group=dev-platform<br />
|source_dirs=netwerk/cookie/<br />
|url=<br />
|components=Core::Networking: Cookies<br />
}}<br />
<br />
{{Module<br />
|name=Permissions<br />
|description=<br />
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:amarchesini@mozilla.com Andrea Marchesini], [mailto:honzab.moz@firemni.cz Honza Bambas]<br />
|ownersemeritus=Monica Chew<br />
|peersemeritus=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]<br />
|group=dev-platform<br />
|source_dirs=extensions/permissions/<br />
|url=<br />
|components=Core :: Permission Manager<br />
}}<br />
<br />
{{Module<br />
|name=Cycle Collector<br />
|description=Code to break and collect objects within reference cycles<br />
|owner=[https://mozillians.org/en-US/u/mccr8/ Andrew McCreight]<br />
|peers=Peter Van der Beken, Olli Pettay, David Baron<br />
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers<br />
|components=Core::XPCOM<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=C++/Rust usage, tools, and style<br />
|description=Aspects of C++ use such as language feature usage, standard library versions/usage, compiler/toolchain versions, formatting and naming style, and aspects of Rust use as needs arise<br />
|owner=[mailto:eakhgari@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:bballo@mozilla.com Botond Ballo], [mailto:glandium@mozilla.com Mike Hommey], [mailto:jwalden@mozilla.com Jeff Walden], [mailto:sgiesecke@mozilla.com Simon Giesecke]<br />
|source_dirs=non-third-party C++ and Rust code in the tree<br />
|components=Various components<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=docshell<br />
|description=<br />
|owner=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:nika@thelayzells.com Nika Layzell]<br />
|peers=[mailto:peterv@propagandism.org Peter Van der Beken], [mailto:afarre@mozilla.com Andreas Farre]<br />
|ownersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:justin.lebar@gmail.com Justin Lebar], [mailto:sawang@mozilla.com Samael Wang], [mailto:kyle@nonpolynomial.com Kyle Machulis]<br />
|group=dev-platform<br />
|source_dirs=docshell/, uriloader/<br />
|url=<br />
|components=Core::Document Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Document Object Model<br />
|description=<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:hsivonen@iki.fi Henri Sivonen], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:baku@mozilla.com Andrea Marchesini],<br />
[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:nika@thelayzells.com Nika Layzell], [mailto:afarre@mozilla.com Andreas Farre], [mailto:emilio@crisal.io Emilio Cobos], [mailto:asuth@mozilla.com Andrew Sutherland]<br />
|ownersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|peersemeritus=[mailto:justin.lebar@gmail.com Justin Lebar], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:bent.mozilla@gmail.com Ben Turner], [mailto:mounir@lamouri.fr Mounir Lamouri], [mailto:me@kylehuey.com Kyle Huey], [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:ben@wanderview.com Ben Kelly], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:kyle@nonpolynomial.com Kyle Machulis], [mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/*, except directories covered by other modules<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML<br />
}}<br />
<br />
{{Module<br />
|name=DOM File<br />
|description=DOM Blob, File and FileSystem APIs <br />
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]<br />
|peers=[mailto:olli@pettay.fi Olli Pettay]<br />
|group=dev-platform<br />
|source_dirs=dom/file, dom/filesystem<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: File<br />
}}<br />
<br />
{{Module<br />
|name=Event Handling<br />
|description=DOM Events and Event Handling <br />
|owner=[mailto:olli@pettay.fi Olli Pettay], [mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:echen@mozilla.com Edgar Chen]<br />
|peersemeritus=[mailto:sshih@mozilla.com Stone Shih]<br />
|group=dev-platform<br />
|source_dirs=dom/events and event handling related code elsewhere <br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: Events, Core::DOM: UI Events & Focus Handling<br />
}}<br />
<br />
{{Module<br />
|name=Web Workers<br />
|description=<br />
|owner=[mailto:baku@mozilla.com Andrea Marchesini]<br />
|peers=[mailto:mrbkap@mozilla.com Blake Kaplan], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey], [mailto:bkelly@mozilla.com Ben Kelly], [mailto:asuth@mozilla.com Andrew Sutherland], [mailto:ytausky@mozilla.com Yaron Tausky]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|group=dev-platform<br />
|source_dirs=dom/workers/<br />
|url=https://developer.mozilla.org/En/Using_web_workers<br />
|components=Core::DOM: Workers<br />
}}<br />
<br />
{{Module<br />
|name=IndexedDB<br />
|description=<br />
|owner=[mailto:jvarga@mozilla.com Jan Varga]<br />
|peers=[mailto:btseng@mozilla.com Bevis Tseng], [mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:baku@mozilla.com Andrea Marchesini]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey]<br />
|group=dev-platform<br />
|source_dirs=dom/indexedDB/<br />
|url=https://developer.mozilla.org/en/IndexedDB<br />
|components=Core::DOM: IndexedDB<br />
}}<br />
<br />
{{Module<br />
|name=Editor<br />
|description=<br />
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-platform<br />
|source_dirs=editor/<br />
|url=http://www.mozilla.org/editor/<br />
|components=Core::Editor<br />
}}<br />
<br />
{{Module<br />
|name=Gecko Profiler<br />
|description=Gecko's built-in profiler<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|peers=[mailto:nnethercote@mozilla.com Nicholas Nethercote], [mailto:gsquelart@mozilla.com Gerald Squelart], [mailto:gtatum@mozilla.com Greg Tatum], [mailto:canaltinova@mozilla.com Nazim Can Altinova], [mailto:jseward@mozilla.com Julian Seward] (LUL), [mailto:kvijayan@mozilla.com Kannan Vijayan] (JS integration), [mailto:brennie@mozilla.com Barret Rennie] (Screenshots).<br />
|ownersemeritus=[mailto:b56girard@gmail.com Benoit Girard]<br />
|peersemeritus=[mailto:shu@mozilla.com Shu-yu Guo] (JS integration), [mailto:tlee@mozilla.com Thinker Lee] (TaskTracer), [mailto:cyu@mozilla.com Cervantes Yu] (TaskTracer)<br />
|group=dev-platform<br />
|source_dirs=tools/profiler/<br />
|url=https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler<br />
|components=Core::Gecko Profiler<br />
}}<br />
<br />
{{Module<br />
|name=Global Key Bindings<br />
|description=Global hot keys in Mozilla for the browser, editor, mail-news and widgets. Does not include underlined menu accelerators and the like, as those are part of i18n.<br />
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|group=dev-accessibility<br />
|source_dirs=dom/events (and platform specific directories under it)<br />
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html<br />
|components=Core::Keyboard: Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Graphics<br />
|description=Mozilla graphics API<br />
|owner=[mailto:jrmuizel@mozilla.com Jeff Muizelaar](Thebes, QCMS, YCbCr, Cairo/Pixman, Regions, OS X, Other)<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:bas.schouten@live.nl Bas Schouten](Layers, Windows), [mailto:jgilbert@mozilla.com Jeff Gilbert](WebGL, ANGLE), [mailto:mwoodrow@mozilla.com Matt Woodrow](Layers API), [mailto:jfkthame@googlemail.com Jonathan Kew](text/fonts), [mailto:nsilva@mozilla.com Nicolas Silva](MozSurface), [mailto:ncameron@mozilla.com Nick Cameron], [mailto:sikeda@mozilla.com Sotaro Ikeda](B2G), [mailto:jnicol@mozilla.com Jamie Nicol](Android), [mailto:snorp@mozilla.com James Willcox](Android), [mailto:mstange@themasta.com Markus Stange](OS X), [mailto:lsalzman@mozilla.com Lee Salzman](Skia, Canvas2D), [mailto:rhunt@mozilla.com Ryan Hunt](OMTP), [mailto:gwatson@mozilla.com Glenn Watson ](WebRender), [mailto:dmalyshau@mozilla.com Dzmitry Malyshau](WebRender)<br />
|peersemeritus=[mailto:bgirard@mozilla.com Benoit Girard](Compositor, Performance), [mailto:ajuma.bugzilla@alijuma.com Ali Juma], [mailto:george@mozilla.com George Wright](Canvas2D), [mailto:mchang@mozilla.com Mason Chang], [mailto:dvander@mozilla.com David Anderson], [mailto:clord@mozilla.com Christopher Lord], [mailto:jdaggett@mozilla.com John Daggett](text/fonts), [mailto:bjacob@mozilla.com Benoit Jacob](gfx/gl), [mailto:jdrew@mozilla.com Joe Drew], [mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=gfx/, dom/canvas/<br />
|url=https://wiki.mozilla.org/Platform/GFX https://wiki.mozilla.org/Gecko:Layers https://wiki.mozilla.org/Gecko:2DGraphicsSketch<br />
|components=Core::Graphics, Core::Graphics: Layers, Core::Graphics: Text, Core::Graphics: WebRender, Core::GFX: Color Management, Core::Canvas: 2D, Core::Canvas: WebGL<br />
}}<br />
<br />
{{Module<br />
|name=WebGPU (Graphics submodule)<br />
|description=WebGPU implementation<br />
|owner=[mailto:dmalyshau@mozilla.com Dzmitry Malyshau]<br />
|peers=[mailto:josh@joshgroves.com Joshua Groves], [mailto:jgilbert@mozilla.com Jeff Gilbert],<br />
|group=dev-platform<br />
|source_dirs=dom/webgpu<br />
|url=https://wiki.mozilla.org/Platform/GFX/WebGPU<br />
|components=Core::Graphics::WebGPU<br />
}}<br />
<br />
{{Module<br />
|name=APZ (Graphics submodule)<br />
|description=Asynchronous panning and zooming<br />
|owner=[mailto:kgupta@mozilla.com Kartikaya Gupta]<br />
|peers=[mailto:bballo@mozilla.com Botond Ballo], [mailto:tnikkel@mozilla.com Timothy Nikkel], [mailto:rhunt@mozilla.com Ryan Hunt], [mailto:mstange@mozilla.com Markus Stange]<br />
|group=dev-platform<br />
|source_dirs=gfx/layers/apz<br />
|url=https://wiki.mozilla.org/Platform/GFX/APZ<br />
|components=Core::Panning and Zooming<br />
}}<br />
<br />
{{Module<br />
|name=Moz2D (Graphics submodule)<br />
|description=Platform independent 2D graphics API<br />
|owner=[mailto:bschouten@mozilla.com Bas Schouten]<br />
|peers=[mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:gwright@mozilla.com George Wright], [mailto:jwatt@jwatt.org Jonathan Watt]<br />
|group=dev-platform<br />
|source=gfx/2d<br />
|url=https://wiki.mozilla.org/Platform/GFX/Moz2D<br />
|components=Core::Graphics<br />
}}<br />
<br />
{{Module<br />
|name=Legacy HTML Parser<br />
|description=<br />
|owner=[mailto:mrbkap@gmail.com Blake Kaplan]<br />
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:rbs@maths.uq.edu.au rbs@maths.uq.edu.au]<br />
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|source_dirs=parser/htmlparser<br />
|url=http://www.mozilla.org/newlayout/doc/parser.html<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=HAL<br />
|description=Hardware Abstraction Layer<br />
|owner=[mailto:gsvelto@mozilla.com Gabriele Svelto]<br />
|peers=<br />
|group=dev-platform<br />
|source_dirs=hal/<br />
|components=Core::Hardware Abstraction Layer (HAL)<br />
}}<br />
<br />
{{Module<br />
|name=HTML Parser<br />
|description=The HTML Parser transforms HTML source code into a DOM. It conforms to the HTML specification, and is mostly translated automatically from Java to C++.<br />
|owner=[mailto:hsivonen@iki.fi Henri Sivonen]<br />
|peers=[mailto:wchen@mozilla.com William Chen]<br />
|group=dev-platform<br />
|source_dirs=parser/html<br />
|url=http://about.validator.nu/<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=I18N Library<br />
|description=<br />
|owner=[mailto:hsivonen@hsivonen.fi Henri Sivonen (encoding)], [mailto:jfkthame@gmail.com Jonathan Kew (except to encoding)]<br />
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura], [mailto:gandalf@aviary.pl Zibi Braniecki], [mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]<br />
|ownersemeritus=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]<br />
|group=dev-i18n<br />
|source_dirs=intl/<br />
|url=http://mozilla.org/projects/intl/index.html<br />
|components=Core::Internationalization<br />
}}<br />
<br />
{{Module<br />
|name=ImageLib<br />
|description=<br />
|owner=[mailto:tnikkel@gmail.com Timothy Nikkel]<br />
|peers=[mailto:aosmond@mozilla.com Andrew Osmond], [mailto:jmuizelaar@mozilla.com Jeff Muizelaar]<br />
|peersemeritus=[mailto:seth.bugzilla@blackhail.net Seth Fowler], [mailto:netzen@gmail.com Brian Bondy], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-platform<br />
|source_dirs=media/libjpeg/, media/libpng/, image/, modules/zlib/<br />
|url=<br />
|components=Core::ImageLib<br />
}}<br />
<br />
{{Module<br />
|name=IPC<br />
|description=Native message-passing between threads and processes<br />
|owner=[mailto:jld@mozilla.com Jed Davis]<br />
|ownersemeritus=Chris Jones, Bill McCloskey<br />
|peers=[mailto:nika@thelayzells.com Nika Layzell], [mailto:jmathies@mozilla.com Jim Mathies], [mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:amccreight@mozilla.com Andrew McCreight]<br />
|peersemeritus=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bent.mozilla@gmail.com Ben Turner], David Anderson, Kan-Ru Chen, Bevis Tseng, Ben Kelly<br />
|group=dev-platform<br />
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/<br />
|url=<br />
|components=Core::IPC}}<br />
<br />
{{Module<br />
|name=JavaScript<br />
|description=JavaScript engine (SpiderMonkey)<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:jdemooij@mozilla.com Jan de Mooij], André Bargull, [mailto:tcampbell@mozilla.com Ted Campbell], [mailto:jcoppeard@mozilla.com Jon Coppeard], [mailto:sphink@gmail.com Steve Fink], [mailto:arai.unmht@gmail.com Tooru Fujisawa], [mailto:evilpies@gmail.com Tom Schuster], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:jwalden@mit.edu Jeff Walden], [mailto:ystartsev@mozilla.com Yulia Startsev], [mailto:mgaudet@mozilla.com Matthew Gaudet], [mailto:iireland@mozilla.com Iain Ireland], [mailto:nicolas.b.pierron@mozilla.com Nicolas Pierron], [mailto:ccullen@mozilla.com Caroline Cullen], [mailto:nfitzgerald@mozilla.com Nick Fitzgerald], [mailto:nnethercote@mozilla.com Nick Nethercote], [mailto:luke@mozilla.com Luke Wagner], [mailto:sunfish@mozilla.com Dan Gohman], [mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peersemeritus=[mailto:brendan@mozilla.org Brendan Eich], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:nmatsakis@mozilla.com Niko Matsakis], [mailto:ejpbruel@mozilla.com Eddy Bruel], [mailto:danderson@mozilla.com David Anderson], [mailto:igor@mir2.org Igor Bukanov], Andreas Gal, [mailto:efaust@mozilla.com Eric Faust], [mailto:khyperia@mozilla.com Ashley Hauck], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:till@tillschneidereit.net Till Schneidereit]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src<br />
|url=http://www.mozilla.org/js/spidermonkey,<br />
http://developer.mozilla.org/en/docs/About_JavaScript<br />
|components=Core::JavaScript Engine<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript JIT<br />
|description=JavaScript engine's JIT compilers (IonMonkey, Baseline)<br />
|owner=[mailto:jdemooij@mozilla.com Jan de Mooij]<br />
|peers=André Bargull, [mailto:bbouvier@mozilla.com Benjamin Bouvier], [mailto:tcampbell@mozilla.com Ted Campbell], [mailto:ccullen@mozilla.com Caroline Cullen], [mailto:mgaudet@mozilla.com Matthew Gaudet], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:iireland@mozilla.com Iain Ireland], [mailto:nicolas.b.pierron@mozilla.com Nicolas Pierron], [mailto:evilpies@gmail.com Tom Schuster], [mailto:sstangl@mozilla.com Sean Stangl], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:luke@mozilla.com Luke Wagner]<br />
|peersemeritus=[mailto:danderson@mozilla.com David Anderson], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:hv1989@gmail.com Hannes Verschore]<br />
|group=dev-tech-js-engine-internals<br />
|source_dirs=js/src/jit<br />
|url=http://www.mozilla.org/js/spidermonkey<br />
|components=Core::JavaScript Engine: JIT<br />
}}<br />
<br />
{{Module<br />
|name=jsat<br />
|description=Javascript screen reader that is used in Android and B2G<br />
|owner=[mailto:eitan@monotonous.org Eitan Isaacson]<br />
|peers=[mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|group=dev-accessibility<br />
|source_dirs=accessible/jsat/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=js-ctypes<br />
|description=A foreign function interface which allows privileged JS code to interact with binary code without using XPCOM/XPConnect.<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src/ctypes/<br />
|url=https://wiki.mozilla.org/JSctypes<br />
|components=Core::js-ctypes<br />
}}<br />
<br />
{{Module<br />
|name=js-tests<br />
|description=JavaScript test suite<br />
|owner=[mailto:bclary@bclary.com Bob Clary]<br />
|peers=<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tests/<br />
|url=http://www.mozilla.org/js/tests/library.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Layout Engine<br />
|description=rendering tree construction, layout (reflow), etc.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:jfkthame@gmail.com Jonathan Kew], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:matt.woodrow@gmail.com Matt Woodrow], [mailto:xidorn+moz@upsuper.org Xidorn Quan], [mailto:emilio@crisal.io Emilio Cobos Álvarez]<br />
|peersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/printing/, layout/tables/, layout/tools/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Layout<br />
|components=Core::Layout, Core::Layout: Block and Inline, Core::Layout: Columns, Core::Layout: Flexbox, Core::Layout: Floats, Core::Layout: Form Controls, Core::Layout: Generated Content, Lists, and Counters, Core::Layout: Grid, Core::Layout: Images, Video, and HTML Frames, Core::Layout: Positioned, Core::Layout: Ruby, Core::Layout: Scrolling and Overflow, Core::Layout: Tables, Core::Layout: Text and Fonts, Core::Print Preview, Core::Printing: Output<br />
}}<br />
<br />
{{Module<br />
|name=libjar<br />
|description=The JAR handling code (protocol handler, stream implementation, and zipreader/zipwriter).<br />
|owner=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|ownersemeritus=Taras Glek, Michael Wu<br />
|peers=[mailto:mnovotny@mozilla.com Michal Novotny], [mailto:vgosu@mozilla.com Valentin Gosu]<br />
|group=dev-platform<br />
|source_dirs=modules/libjar<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MathML<br />
|description=MathML is a low-level specification for describing mathematics which provides a foundation for the inclusion of mathematical expressions in Web pages.<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-tech-mathml<br />
|source_dirs=layout/mathml/<br />
|url=http://www.mozilla.org/projects/mathml/<br />
|components=Core::MathML<br />
}}<br />
<br />
{{Module<br />
|name=Media Playback<br />
|description=HTML Media APIs, including Media Source Extensions and non-MSE video/audio element playback, and Encrypted Media Extensions. (WebRTC and WebAudio not included).<br />
|owner=[mailto:jyavenard@mozilla.com Jean-Yves Avenard]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:cpearce@mozilla.com Chris Pearce]<br />
|peers=[mailto:kinetik@flim.org Matthew Gregan], [mailto:bvandyk@mozilla.com Bryce Van Dyk], [mailto:jolin@mozilla.com John Lin], [mailto:alwu@mozilla.com Alastor Wu], [mailto:jwwang@mozilla.com JW Wang]<br />
|group=dev-media<br />
|source_dirs=dom/media, media/gmp-clearkey/, media/libcubeb/, media/libnestegg/, media/libogg/, media/libopus/, media/libstagefright/, media/libtheora/, media/libtremor/, media/libvorbis/, media/libvpx/, media/omx-plugin/, media/rlz/<br />
|url=<br />
|components=Core::Audio/Video<br />
}}<br />
<br />
{{Module<br />
|name=Media Transport<br />
|description=Pluggable transport for real-time media<br />
|owner=[mailto:ekr@rtfm.com Eric Rescorla]<br />
|peers=[mailto:bcampen@mozilla.com Byron Campen], [mailto:abr@mozilla.com Adam Roach], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]<br />
|group=dev-media<br />
|source_dirs=media/mtransport<br />
|url=<br />
|components=Core::WebRTC::Networking<br />
}}<br />
<br />
{{Module<br />
|name=Memory Allocator<br />
|description=Most things related to memory allocation in Gecko, including jemalloc, replace-malloc, DMD (dark matter detector), logalloc, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:n.nethercote@gmail.com Nicholas Nethercote], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-platform<br />
|source_dirs=memory/<br />
|components=Core::DMD, Core::jemalloc<br />
}}<br />
<br />
{{Module<br />
|name=mfbt<br />
|description=mfbt is a collection of headers, macros, data structures, methods, and other functionality available for use and reuse throughout all Mozilla code (including SpiderMonkey and Gecko more broadly).<br />
|owner=[mailto:jwalden@mit.edu Jeff Walden]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:Ms2ger@gmail.com Ms2ger], [mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|group=dev-platform<br />
|source_dirs=mfbt/<br />
|url=<br />
|components=Core::MFBT<br />
}}<br />
<br />
{{Module<br />
|name=Mozglue<br />
|description=Glue library containing various low-level functionality, including a dynamic linker for Android, a DLL block list for Windows, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd] (mozglue/linker), [mailto:kgupta@mozilla.com Kartikaya Gupta] (mozglue/android), [mailto:nchen@mozilla.com Jim Chen] (mozglue/android), [mailto:aklotz@mozilla.com Aaron Klotz] (Windows Dll Blocklist/Interceptor)<br />
|group=dev-platform<br />
|source_dirs=mozglue/<br />
|components=Core::mozglue<br />
}}<br />
<br />
{{Module<br />
|name=mozilla-toplevel<br />
|description=The top level directory for the mozilla tree.<br />
|owner=[[Modules/Firefox_Technical_Leadership|Firefox Technical Leadership module]]<br />
|ownersemeritus=[mailto:brendan@mozilla.org Brendan Eich]<br />
|peers=<br />
|group=<br />
|source_dirs=tools/README<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MSCOM<br />
|description=Integration with Microsoft Distributed COM<br />
|owner=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|peers=[mailto:jteh@mozilla.com James Teh], [mailto:jmathies@mozilla.com Jim Mathies]<br />
|group=dev-platform<br />
|source_dirs=ipc/mscom/%<br />
|url=<br />
|components=Core::IPC: MSCOM}}<br />
<br />
{{Module<br />
|name=Necko<br />
|description=The Mozilla Networking Library<br />
|owner=[mailto:dd.mozilla@gmail.com Dragana Damjanovic]<br />
|peers= [mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:mnovotny@mozilla.com Michal Novotny], [mailto:valentin.gosu@gmail.com Valentin Gosu], [mailto:kershaw@mozilla.com Kershaw Chang], [mailto:juhsu@mozilla.com Junior Hsu]<br />
|ownersemeritus=[mailto:mcmanus@ducksong.com Patrick McManus], [mailto:cbiesinger@gmail.com Christian Biesinger] |peersemeritus= Shih-Chiang Chien, [mailto:bzbarsky@mit.edu Boris Zbarsky], Steve Workman, Nick Hurley, [mailto:daniel@haxx.se Daniel Stenberg ], [mailto:jduell.mcbugs@gmail.com Jason Duell]<br />
|group=dev-tech-network<br />
|source_dirs=netwerk/%, netwerk/base/, netwerk/build/, netwerk/cache/, netwerk/dns/, netwerk/locales/, netwerk/mime/, netwerk/protocol/, netwerk/resources/, netwerk/socket/, netwerk/streamconv/, netwerk/system/, netwerk/test/, netwerk/testserver/<br />
|url=http://www.mozilla.org/projects/netlib/, https://developer.mozilla.org/en/Necko<br />
|components=Core::Networking, Core::Networking: Cache, Core::Networking: Cookies, Core::Networking: FTP, Core::Networking: File, Core::Networking: HTTP, Core::Networking: JAR, Core::Networking: Websockets<br />
}}<br />
<br />
{{Module<br />
|name=NodeJS usage, tools, and style<br />
|description=Advises on the use of NodeJS and npm packages at build and runtime. Reviews additions/upgrades/removals of vendored npm packages. Works with appropriate teams to maintain automated license and security audits of npm packages. Works with the security team and relevant developers to respond to vulnerabilities in NodeJS and vendored npm packages.<br />
|owner=[mailto:dmosedale@mozilla.com Dan Mosedale]<br />
|peers=[mailto:mbanner@mozilla.com Mark Banner], [mailto:dcoates@mozilla.com Danny Coates], [mailto:khudson@mozilla.com Kate Hudson], [mailto:jlaster@mozilla.com Jason Laster], [mailto:elee@mozilla.com Ed Lee], [mailto:dtownsend@mozilla.com Dave Townsend]<br />
|source_dirs=package.json, package-lock.json, node_modules and others as appropriate<br />
|components=Various components<br />
|forum=[https://wiki.mozilla.org/Firefox/firefox-dev firefox-dev], #nodejs on slack<br />
}}<br />
<br />
{{Module<br />
|name=NSPR<br />
|description=Netscape Portable Runtime<br />
|owner=[mailto:kaie@kuix.de Kai Engert]<br />
|peers=[mailto:mh@glandium.org Mike Hommey]<br />
|ownersemeritus=[mailto:wtc@google.com Wan-Teh Chang]<br />
|group=dev-tech-nspr<br />
|source_dirs=nsprpub/<br />
|url=http://www.mozilla.org/projects/nspr/<br />
http://www.mozilla.org/projects/nspr/reference/html/<br />
http://www.mozilla.org/projects/nspr/release-notes/<br />
|components=NSPR<br />
}}<br />
<br />
{{Module<br />
|name=PDF<br />
|description=Rendering code to display documents encoded in the ISO 32000-1 `PDF' format.<br />
|owner=[mailto:bdahl@mozilla.com Brendan Dahl]<br />
|peers=[mailto:aadib@mozilla.com Artur Adib], [mailto:vnicolas@mozilla.com Vivien Nicolas]<br />
|group=dev-platform<br />
|source_dirs=media/pdf/<br />
|url=https://github.com/mozilla/pdf.js<br />
|components=Core::PDF<br />
}}<br />
<br />
{{Module<br />
|name=Plugins<br />
|description= NPAPI Plugin support.<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:davidp99@gmail.com David Parks]<br />
|peersemeritus=[mailto:joshmoz@gmail.com Josh Aas], [mailto:john@pointysoftware.net John Schoenick], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:jstenback@gmail.com Johnny Stenback], Benjamin Smedberg<br />
|group=<br />
|source_dirs=dom/plugins/, modules/plugin/<br />
|url=https://wiki.mozilla.org/Plugins<br />
|components=Core::Plug-ins<br />
}}<br />
<br />
{{Module<br />
|name=Preferences<br />
|description=Preference library<br />
|owner=[mailto:nnethercote@mozilla.com Nicholas Nethercote]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:glandium@mozilla.com Mike Hommey], [mailto:kwright@mozilla.com Kristen Wright]<br />
|peersemeritus=Felipe Gomes, Eric Rahm<br />
|group=dev-platform<br />
|source_dirs=modules/libpref/<br />
|url=<br />
|components=Core::Preferences: Backend<br />
}}<br />
<br />
{{Module<br />
|name=Private Browsing<br />
|description=Implementation of the Private Browsing mode, and the integration of other modules with Private Browsing APIs.<br />
|owner=[mailto:eakhgari@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:josh@joshmatthews.net Josh Matthews]<br />
|group=dev-platform<br />
|source_dirs=Implementation and consumers of Private Browsing APIs in nsILoadContext, nsIPrivateBrowsingChannel, PrivateBrowsingUtils.jsm and the related glue code. <br />
|url=https://wiki.mozilla.org/Private_Browsing<br />
|components=Firefox::Private Browsing<br />
}}<br />
<br />
{{Module<br />
|name=Privilege Manager<br />
|description="caps"<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]<br />
|peersemeritus=[mailto:brendan@mozilla.org Brendan Eich], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:dveditz@mozilla.com Dan Veditz]<br />
|group=dev-tech-dom<br />
|source_dirs=caps/<br />
|url=http://www.mozilla.org/projects/security/components/index.html<br />
|components=Core::Security: CAPS<br />
}}<br />
<br />
{{Module<br />
|name=Push Notifications<br />
|description=Push is a way for application developers to send messages to their web applications.<br />
|owners=[mailto:lina@mozilla.com Lina Cambridge]<br />
|ownersemeritus=[mailto:doug.turner@gmail.com Doug Turner]<br />
|peers=[mailto:mt@lowentropy.net Martin Thomson], [mailto:ddamjanovic@mozilla.com Dragana Damjanovic]<br />
|peersemeritus=[mailto:nsm.nikhil@gmail.com Nikhil Marathe]<br />
|group=<br />
|source_dirs=dom/push<br />
|url=<br />
|components=Core::DOM: Push Notifications<br />
}}<br />
<br />
{{Module<br />
|name=security<br />
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)<br />
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:mt@lowentropy.net Martin Thomson]<br />
|ownersemeritus=[mailto:wtc@google.com Wan-Teh Chang], [mailto:ttaubert@mozilla.com Tim Taubert]<br />
|peers=[mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi], [mailto:ekr@rtfm.com Eric Rescorla], [mailto:franziskuskiefer@gmail.com Franziskus Kiefer], [mailto:dueno@redhat.com Daiki Ueno]<br />
|peersemeritus=[mailto:emaldona@redhat.com Elio Maldonado]<br />
|group=dev-tech-crypto<br />
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/<br />
|url=http://mozilla.org/projects/security/pki/<br />
|components=NSS, JSS, Core::Security, Core::Security: S/MIME<br />
}}<br />
<br />
{{Module<br />
|name=Security - Mozilla PSM Glue<br />
|description=Personal Security Manager<br />
|owner=[mailto:dkeeler@mozilla.com Dana Keeler]<br />
|ownersemeritus=[mailto:kaie@kuix.de Kai Engert (2001-2012)]<br />
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:cykesiopka.bmo@gmail.com Cykesiopka], [mailto:jc@mozilla.com J.C. Jones], [mailto:fkiefer@mozilla.com Franziskus Kiefer]<br />
|group=dev-tech-crypto<br />
|source_dirs=security/manager/<br />
|url=<br />
|components=Core::Security: PSM<br />
}}<br />
<br />
{{Module<br />
|name=Static analysis & rewriting for C++<br />
|description=Tools for checking C++ code looking for problems at compile time, plus tools for automated rewriting of C++ code.<br />
|owner=[mailto:andi@mozilla.com Andi-Bogdan Postelnicu]<br />
|peers=[mailto:nika@thelayzells.com Nika Layzell], [mailto:sfink@mozilla.com Steve Fink], [mailto:jrmuizel@mozilla.com Jeff Muizelaar], [mailto:eakhgari@mozilla.com Ehsan Akhgari]<br />
|peersemeritus=[mailto:birunthan@mohanathas.com Birunthan Mohanathas]<br />
|group=dev-platform<br />
|source_dirs=build/clang-plugin, tools/rewriting among other out of tree tools<br />
|url=<br />
|components=Core::Rewriting & Analysis<br />
}}<br />
{{Module<br />
|name=storage<br />
|description=Storage APIs with a SQLite backend<br />
|owner=[mailto:mak77@bonardo.net Marco Bonardo]<br />
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:jvarga@mozilla.com Jan Varga]<br />
|group=dev-platform<br />
|source_dirs=db/sqlite3/, storage/<br />
|url=http://developer.mozilla.org/en/docs/Storage<br />
|components=Toolkit::Storage, Core::SQL<br />
}}<br />
<br />
{{Module<br />
|name=String<br />
|description=<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-tech-xpcom<br />
|source_dirs=string/, xpcom/string/<br />
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide<br />
|components=Core::String<br />
}}<br />
<br />
{{Module<br />
|name=Style System<br />
|description=CSS style sheet handling; style data computation<br />
|owner=[mailto:cam@mcc.id.au Cameron McCormack]<br />
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:emilio@crisal.io Emilio Cobos Álvarez], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:xidorn+moz@upsuper.org Xidorn Quan], [mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/style/, servo/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System<br />
|components=Core::CSS Parsing and Computation<br />
}}<br />
<br />
{{Module<br />
|name=SVG<br />
|description=Scalable Vector Graphics<br />
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]<br />
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]<br />
|group=dev-tech-svg<br />
|source_dirs=dom/svg/, layout/svg/, dom/smil/<br />
|url=https://developer.mozilla.org/en-US/docs/Web/SVG<br />
|components=Core::SVG<br />
}}<br />
<br />
{{Module<br />
|name=View System<br />
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]<br />
|group=dev-tech-layout<br />
|source_dirs=view/<br />
|url=<br />
|components=Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=Web Audio<br />
|description=Support for the W3C Web Audio API specification.<br />
|owner=[mailto:padenot@mozilla.com Paul Adenot]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:karlt+@karlt.net Karl Tomlinson]<br />
|group=dev-platform<br />
|source_dirs=dom/media/webaudio<br />
|url=https://wiki.mozilla.org/Web_Audio_API<br />
|components=Core::Web Audio<br />
}}<br />
<br />
{{Module<br />
|name=Web Painting<br />
|description=painting, display lists, and layer construction<br />
|owner=[mailto:matt.woodrow@gmail.com Matt Woodrow]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dbaron@dbaron.org David Baron], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:mstange@themasta.com Markus Stange], [mailto:mmynttinen@mozilla.com Miko Mynttinen], [mailto:jnicol@mozilla.com Jamie Nicol]<br />
|group=dev-tech-layout<br />
|source_dirs= layout/painting, the display list and layer related methods on nsIFrame and its subclasses<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|components=Core::Layout: Web Painting<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC<br />
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=netwerk/sctp (also see submodules "WebRTC Media" and "WebRTC Signaling")<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC, Core::WebRTC Networking<br />
}}<br />
<br />
{{Module<br />
|name=WebVR<br />
|description=Gecko's implementation of WebVR (Virtual Reality) functionality, including API, devices, graphics and integration<br />
|owner=[mailto:kgilbert@mozilla.com Kearwood (Kip) Gilbert]<br />
|peers=[mailto:dmu@mozilla.com Daosheng Mu], [mailto:igorostizaga@mozilla.com Imanol Fernández]<br />
|peersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=dom/vr, gfx/vr<br />
|url=https://mozvr.com/<br />
|components=Core::WebVR<br />
}}<br />
<br />
{{Module<br />
|name=Widget<br />
|description=Top level Widget<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|ownersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peersemeritus=[mailto:pavlov@pavlov.net Stuart Parmenter], <br />
|group=dev-platform<br />
|source_dirs=widget/, widget/xpwidgets/<br />
|url=<br />
|components=Core::Drag and Drop, Core::Widget, Core::Printing: Setup<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Android<br />
|description=Android widget support<br />
|owner=[mailto:jwillcox@mozilla.com James Willcox]<br />
|peers=<br />
|ownersemeritus=[mailto:blassey.bugs@lassey.us Brad Lassey]<br />
|group=dev-platforms-mobile<br />
|source_dirs=widget/android/, embedding/android<br />
|url=<br />
|components=Core::Widget: Android<br />
}}<br />
<br />
{{Module<br />
|name=Widget - GTK<br />
|description=GTK widget support<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:stransky@redhat.com Martin Stránský]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-platform<br />
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/<br />
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/<br />
|components=Core::Widget: Gtk<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Headless<br />
|description=Headless widget support<br />
|owner=[mailto:bdahl@mozilla.com Brendan Dahl]<br />
|peers=<br />
|ownersemeritus=<br />
|group=dev-platform<br />
|source_dirs=widget/headless/<br />
|url=<br />
|components=Firefox::Headless<br />
}}<br />
<br />
{{Module<br />
|name=Widget - macOS<br />
|description= macOS widget support<br />
|owner=[mailto:spohl@mozilla.com Stephen A Pohl]<br />
|peers=[mailto:mstange@themasta.com Markus Stange], [mailto:haftandilian@mozilla.com Haik Aftandilian]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:mstange@themasta.com Markus Stange]<br />
|peersemeritus=[mailto:joshmoz@gmail.com Josh Aas], [mailto:b56girard@gmail.com Benoit Girard], [mailto:smichaud@pobox.com Steven Michaud]<br />
|group=dev-platform<br />
|source_dirs=widget/cocoa/<br />
|url=<br />
|components=Core::Widget: Cocoa<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Windows<br />
|description=Windows widget support<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:cmartin@mozilla.com Chris Martin], [mailto:tkikuchi@mozilla.com Toshihito Kikuchi], [mailto:mhowell@mozilla.com Molly Howell], [mailto:aklotz@mozilla.com Aaron Klotz], [mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|peersemeritus=[mailto:robert.strong.bugs@gmail.com Rob Strong], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:doug.turner@gmail.com Doug Turner], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:robarnold@cmu.edu Rob Arnold]<br />
|group=dev-platform<br />
|source_dirs=widget/windows/<br />
|url=<br />
|components=Core::Widget: Win32<br />
}}<br />
<br />
{{Module<br />
|name=XML<br />
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-xml<br />
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/<br />
|url=http://www.mozilla.org/newlayout/xml/<br />
|components=Core::XML<br />
}}<br />
<br />
{{Module<br />
|name=XPApps<br />
|description=Cross-Platform Applications, mostly Navigator front end and application shell.<br />
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-apps-seamonkey<br />
|source_dirs=xpfe/<br />
|url=http://www.mozilla.org/xpapps/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPCOM<br />
|description=The cross-platform object model and core data structures.<br />
|owner=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]<br />
|peers=[mailto:erahm@mozilla.com Eric Rahm], [mailto:nika@thelayzells.com Nika Layzell], [mailto:kmaglione@mozilla.com Kris Maglione]<br />
|ownersemeritus=Benjamin Smedberg<br />
|peersemeritus=[https://mozillians.org/en-US/u/dougt/ Doug Turner]<br />
|group=dev-platform<br />
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/<br />
|url=http://developer.mozilla.org/en/XPCOM<br />
|components=Core::XPCOM<br />
}}<br />
<br />
{{Module<br />
|name=XPConnect<br />
|description=Deep Magic<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:kmaglione@mozilla.com Kris Maglione], [mailto:nika@thelayzells.com Nika Layzell]<br />
|peersemeritus=[mailto:gal@uci.edu Andreas Gal], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]<br />
|group=<br />
|source_dirs=js/xpconnect/<br />
|url=<br />
|components=Core::XPConnect<br />
}}<br />
<br />
{{Module<br />
|name=XPIDL<br />
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.<br />
|owner=[mailto:nika@thelayzells.com Nika Layzell]<br />
|peers=[mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:amccreight@mozilla.com Andrew McCreight]<br />
|ownersemeritus=[mailto:me@kylehuey.com Kyle Huey]<br />
|peersemeritus=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-tech-xpcom<br />
|source_dirs=xpcom/typelib/<br />
|url=http://www.mozilla.org/scriptable/xpidl<br />
http://www.mozilla.org/scriptable<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XSLT Processor<br />
|description=XSLT transformations processor<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xslt<br />
|source_dirs=dom/xslt/<br />
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html<br />
|components=Core::XSLT<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Windows <br />
|description=Sandboxing for the Windows platform <br />
|owner=[mailto:bobowencode@gmail.com Bob Owen] (:bobowen)<br />
|peers=[mailto:aklotz@mozilla.com Aaron Klotz] (:aklotz), [mailto:jimm@mozilla.com Jim Mathies] (:jimm), [mailto:davidp99@gmail.com David Parks] (:handyman)<br />
|ownersemeritus=[https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes]<br />
|peersemeritus=[mailto:netzen@gmail.com Brian Bondy]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/win <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - OSX <br />
|description=Sandboxing for the OSX platform <br />
|owner=[mailto:haftandilian@mozilla.com Haik Aftandilian]<br />
|peers=<br />
|group=dev-platform <br />
|source_dirs=security/sandbox/mac <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Linux<br />
|description=Sandboxing for the Linux platform<br />
|owner=[mailto:jld@mozilla.com Jed Davis]<br />
|peers=[mailto:gcp@mozilla.com Gian-Carlo Pascutto]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/linux<br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Crash reporting<br />
|description=Infrastructure and tools used to generate, submit and process crash reports. This includes the in-tree google-breakpad fork, the crash report generation machinery as well as the host tools used to dump symbols, analyse minidumps and generate stack traces.<br />
|owner=[mailto:gsvelto@mozilla.com Gabriele Svelto] (:gsvelto)<br />
|peers=[mailto:nfroyd@mozilla.com Nathan Froyd] (:froydnj)<br />
|group=dev-platform<br />
|source_dirs=toolkit/crashreporter, toolkit/components/crashes, tools/crashreporter, ipc/glue/CrashReporter*, mobile/android/geckoview/src/main/java/org/mozilla/geckoview/CrashReporter.java<br />
|url=https://firefox-source-docs.mozilla.org/toolkit/crashreporter/crashreporter/index.html<br />
|components=Toolkit::Crash Reporting<br />
}}<br />
<br />
===Submodules===<br />
{{Module<br />
|name=Build Config - Fennec<br />
|description=Submodule of the build config covering Fennec's build system in mobile/android.<br />
|owner=[mailto:nalexander@mozilla.com Nicholas Alexander]<br />
|peers=Same as Build Config<br />
|group=dev-builds<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Build Config - Taskgraph<br />
|description=Support for task-graph generation in decision, action, and cron tasks, including configuration of all tasks including those for CI, nightlies, and releases; as well as Docker and VM images used to execute those tasks.<br />
|owner=[mailto:mozilla@hocat.ca Tom Prince]<br />
|peers=[mailto:ahal@mozilla.com Andrew Halberstadt], [mailto:aki@mozilla.com Aki Sasaki], [mailto:bstack@mozilla.com Brian Stack], [mailto:mh@glandium.org Mike Hommey], [mailto:gps@mozilla.com Gregory Szorc], [mailto:jmaher@mozilla.com Joel Maher], [mailto:callek@mozilla.com Justin Wood], [mailto:dustin@mozilla.com Dustin Mitchell]<br />
|components=Firefox Build System::Task Configuration<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Media<br />
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:jib@mozilla.com Jan-Ivar Bruaroey], [mailto:dminor@mozilla.com Dan Minor], [mailto:apehrson@mozilla.com Andreas Pehrson], <br />
|peersemeritus=[mailto:pkerr@mozilla.com Paul Kerr], [mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc, /dom/media/webrtc, /dom/media/systemservices<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Audio/Video)<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Signaling<br />
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling<br />
|owner=[mailto:bcampen@mozilla.com Byron Campen]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:abr@mozilla.com Adam Roach], [mailto:rjesup@mozilla.com Randell Jesup], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc/signaling/<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Signaling)<br />
}}<br />
<br />
<noinclude><br />
<br />
===Unassigned Bugzilla Components===<br />
<br />
The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):<br />
<br />
<pre><br />
Core::Find Backend<br />
Core::General<br />
Core::History: Global<br />
Core::Image Blocking<br />
Core::Localization<br />
Core::Networking: Domain Lists<br />
Core::Selection<br />
Core::Serializers<br />
Core::Spelling checker<br />
Core::X-remote<br />
Core::XUL<br />
</pre><br />
</noinclude></div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1228889Oxidation2020-07-09T00:46:16Z<p>Nnethercote: /* Rust in Firefox */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more productive to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety. Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
* High performance. In particular, the safety enables code that is designed more actively for performance, especially parallel performance.<br />
* Nimbleness. The safety enables significant changes to existing code to be made quickly and with confidence.<br />
* Expressiveness. It is powerful and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent package management and an extensive ecosystem.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A friendly and helpful community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating. (The new borrow checker released in Rust 1.31 helped greatly with this.)<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
Policy<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
<br />
Rust in Firefox docs<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Adding Rust code]<br />
* [https://firefox-source-docs.mozilla.org/writing-rust-code/index.html Writing Rust code]<br />
* [https://firefox-source-docs.mozilla.org/testing-rust-code/index.html Testing & debugging Rust code]<br />
<br />
Getting extra help<br />
* The Rust channel on [https://wiki.mozilla.org/Matrix Mozilla's Matrix network] contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Statistics ===<br />
<br />
* [https://docs.google.com/spreadsheets/d/1flUGg6Ut4bjtyWdyH_9emD9EAN01ljTAVft2S4Dq620/edit#gid=885787479 Lines of compiled Rust code shipped in Firefox (over time)]<br />
* [https://4e6.github.io/firefox-lang-stats/ Lines of Rust code in mozilla-central (current)]<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* libcubeb Audio backend for Linux (PulseAudio): {{bug|1346665}} (shipped in Firefox 59)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety assist productivity, and allow more aggressive optimizations.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* Profiler symbolication: {{bug|1509549}} (shipped in Firefox 67)<br />
** '''Why Rust?''' Makes use of existing crates that handle object file parsing and symbol iteration. Easy to compile to WebAssembly.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* [https://github.com/padenot/audio_thread_priority audio_thread_priority] {{bug|1429847}} (shipped in Firefox 69), allow promoting threads to a real-time scheduling class, on Windows/Linux/macOS.<br />
** '''Why Rust?''' This crate is being used by C++ code and by Rust code (audioipc), Rust is nicer to write than C++ (especially for what is essentially just a series of system calls, the error checking style is nice), and cbindgen made it trivial to expose a C ABI.<br />
* [https://github.com/mozilla/dogear/ Dogear] a bookmark merger for Sync. Shipped pref'd-off in {{bug|1482608}} (Firefox 68), enabled by default in {{bug|1588005}} (shipped in Firefox 72)<br />
** '''Why Rust?''' A single performant and safe implementation shared between desktop and the bookmarks engine in [https://github.com/mozilla/application-services/tree/master/components/places application-services]<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Replace libhyphen with mapped_hyph, {{bug|1590167}} (shipped in Firefox 72).<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}} (shipped in Firefox 76)<br />
** '''Why Rust?''' Performance and memory wins are substantial over previous JS implementation. It brings zero-copy parsing, and memory savvy resolving of localization strings. It also paves the way for migrating the rest of the Fluent APIs away from JS which is required for Fission.<br />
<br />
=== In progress ===<br />
<br />
* Port [https://github.com/projectfluent/fluent-rs Localization API] to Rust: {{bug|1613705}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend SmooshMonkey] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues. This also allows us to tailor the SDP parser specifically for the subset used in WebRTC, further reducing its surface area. It is currently run in parallel with the C parser in Nightly.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* libcubeb Audio backend for macOS (CoreAudio): {{bug|1530715}} (in Nightly since 70?)<br />
* [https://github.com/gfx-rs/wgpu wgpu], a [https://gpuweb.github.io/gpuweb/ WebGPU] API implementation: {{bug|webgpu-mvp}} (in Nightly since 72)<br />
** '''Why Rust?''' Complex tracking logic, wide attack area. Also, leverages Rust ecosystem for building libraries on top of our native implementation and the API that will target the Web.<br />
* Integrate the [https://github.com/mozilla/glean/ Glean SDK], a data collection library.<br />
<br />
=== Proposed ===<br />
<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
* [https://github.com/mozilla/application-services Sync/FxA components]<br />
** '''Why Rust?''' Single safe and performant implementation which is shared across all our products.<br />
* libcubeb Audio backend for Windows (WASAPI)<br />
* Replace the XML parser, possibly via c2rust: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
* Rewrite the ICE stack used by WebRTC; {{bug|1616966}}<br />
** '''Why Rust?''' Works with network data.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
** [https://github.com/mozilla/dump_syms/ dump_syms], a reimplementation of Google Breakpad's dump_syms tool for Windows. Used to parse PDB files and print out Breakpad-compatible symbol files. <br />
*** '''Why Rust?''' Doesn't rely on Microsoft closed-source libraries anymore, can be cross-compiled and run on a non-Windows host, is an order of magnitude faster, takes less than a third of the memory, produces better symbols and relies on an active and friendly upstream [https://github.com/getsentry/symbolic/ symbolic]<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/components various sync-related components used on iOS and Fenix], includes a cross-compiled FxA Rust client, and storage/syncing of bookmarks, history, logins, tabs and webextensions data.<br />
* [https://github.com/mozilla/fix-stacks/ fix-stacks], a stack frame symbolizer: {{bug|1596292}}<br />
** '''Why Rust?''' High performance needed, a single implementation can replace multiple platform-specific scripts, and we can use the [https://github.com/getsentry/symbolic/ symbolic] crate to do all the hard parts.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* [https://docs.google.com/document/d/16FgQPRxNb-Z6sfJy_P7edXzMVWE86jJEZVbmV0oC-m0/ 2020 Questionnaire results]<br />
* [https://docs.google.com/document/d/1puZvhWaURtViz8OC0HkB0h2dqJThVyAgLGFbIQpd4fo/ Oxidation 2020 Plan]<br />
<br />
= Meetings =<br />
<br />
* Berlin, January 2020 (minutes lost due to technical issues, unfortunately)<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1228531Oxidation2020-06-29T01:26:05Z<p>Nnethercote: /* Documentation and assistance */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more productive to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety. Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
* High performance. In particular, the safety enables code that is designed more actively for performance, especially parallel performance.<br />
* Nimbleness. The safety enables significant changes to existing code to be made quickly and with confidence.<br />
* Expressiveness. It is powerful and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent package management and an extensive ecosystem.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A friendly and helpful community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating. (The new borrow checker released in Rust 1.31 helped greatly with this.)<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
Policy<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
<br />
Rust in Firefox docs<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Adding Rust code]<br />
* Writing Rust code<br />
** [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
** [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
** [https://crisal.io/words/2020/02/28/C++-rust-ffi-patterns-1-complex-data-structures.html FFI patterns #1 - Complex Rust data structures exposed seamlessly to C++]<br />
** [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Rust <--> C/C++ FFI for newbies]<br />
* [https://firefox-source-docs.mozilla.org/testing-rust-code/index.html Testing & debugging Rust code]<br />
<br />
Getting extra help<br />
* The Rust channel on [https://wiki.mozilla.org/Matrix Mozilla's Matrix network] contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Statistics ===<br />
<br />
* [https://docs.google.com/spreadsheets/d/1flUGg6Ut4bjtyWdyH_9emD9EAN01ljTAVft2S4Dq620/edit#gid=885787479 Lines of compiled Rust code shipped in Firefox (over time)]<br />
* [https://4e6.github.io/firefox-lang-stats/ Lines of Rust code in mozilla-central (current)]<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* libcubeb Audio backend for Linux (PulseAudio): {{bug|1346665}} (shipped in Firefox 59)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety assist productivity, and allow more aggressive optimizations.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* Profiler symbolication: {{bug|1509549}} (shipped in Firefox 67)<br />
** '''Why Rust?''' Makes use of existing crates that handle object file parsing and symbol iteration. Easy to compile to WebAssembly.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* [https://github.com/padenot/audio_thread_priority audio_thread_priority] {{bug|1429847}} (shipped in Firefox 69), allow promoting threads to a real-time scheduling class, on Windows/Linux/macOS.<br />
** '''Why Rust?''' This crate is being used by C++ code and by Rust code (audioipc), Rust is nicer to write than C++ (especially for what is essentially just a series of system calls, the error checking style is nice), and cbindgen made it trivial to expose a C ABI.<br />
* [https://github.com/mozilla/dogear/ Dogear] a bookmark merger for Sync. Shipped pref'd-off in {{bug|1482608}} (Firefox 68), enabled by default in {{bug|1588005}} (shipped in Firefox 72)<br />
** '''Why Rust?''' A single performant and safe implementation shared between desktop and the bookmarks engine in [https://github.com/mozilla/application-services/tree/master/components/places application-services]<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Replace libhyphen with mapped_hyph, {{bug|1590167}} (shipped in Firefox 72).<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}} (shipped in Firefox 76)<br />
** '''Why Rust?''' Performance and memory wins are substantial over previous JS implementation. It brings zero-copy parsing, and memory savvy resolving of localization strings. It also paves the way for migrating the rest of the Fluent APIs away from JS which is required for Fission.<br />
<br />
=== In progress ===<br />
<br />
* Port [https://github.com/projectfluent/fluent-rs Localization API] to Rust: {{bug|1613705}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend SmooshMonkey] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues. This also allows us to tailor the SDP parser specifically for the subset used in WebRTC, further reducing its surface area. It is currently run in parallel with the C parser in Nightly.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* libcubeb Audio backend for macOS (CoreAudio): {{bug|1530715}} (in Nightly since 70?)<br />
* [https://github.com/gfx-rs/wgpu wgpu], a [https://gpuweb.github.io/gpuweb/ WebGPU] API implementation: {{bug|webgpu-mvp}} (in Nightly since 72)<br />
** '''Why Rust?''' Complex tracking logic, wide attack area. Also, leverages Rust ecosystem for building libraries on top of our native implementation and the API that will target the Web.<br />
* Integrate the [https://github.com/mozilla/glean/ Glean SDK], a data collection library.<br />
<br />
=== Proposed ===<br />
<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
* [https://github.com/mozilla/application-services Sync/FxA components]<br />
** '''Why Rust?''' Single safe and performant implementation which is shared across all our products.<br />
* libcubeb Audio backend for Windows (WASAPI)<br />
* Replace the XML parser, possibly via c2rust: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
* Rewrite the ICE stack used by WebRTC; {{bug|1616966}}<br />
** '''Why Rust?''' Works with network data.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
** [https://github.com/mozilla/dump_syms/ dump_syms], a reimplementation of Google Breakpad's dump_syms tool for Windows. Used to parse PDB files and print out Breakpad-compatible symbol files. <br />
*** '''Why Rust?''' Doesn't rely on Microsoft closed-source libraries anymore, can be cross-compiled and run on a non-Windows host, is an order of magnitude faster, takes less than a third of the memory, produces better symbols and relies on an active and friendly upstream [https://github.com/getsentry/symbolic/ symbolic]<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/components various sync-related components used on iOS and Fenix], includes a cross-compiled FxA Rust client, and storage/syncing of bookmarks, history, logins, tabs and webextensions data.<br />
* [https://github.com/mozilla/fix-stacks/ fix-stacks], a stack frame symbolizer: {{bug|1596292}}<br />
** '''Why Rust?''' High performance needed, a single implementation can replace multiple platform-specific scripts, and we can use the [https://github.com/getsentry/symbolic/ symbolic] crate to do all the hard parts.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* [https://docs.google.com/document/d/16FgQPRxNb-Z6sfJy_P7edXzMVWE86jJEZVbmV0oC-m0/ 2020 Questionnaire results]<br />
* [https://docs.google.com/document/d/1puZvhWaURtViz8OC0HkB0h2dqJThVyAgLGFbIQpd4fo/ Oxidation 2020 Plan]<br />
<br />
= Meetings =<br />
<br />
* Berlin, January 2020 (minutes lost due to technical issues, unfortunately)<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1228487Oxidation2020-06-26T02:22:38Z<p>Nnethercote: /* Rust in Firefox */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more productive to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety. Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
* High performance. In particular, the safety enables code that is designed more actively for performance, especially parallel performance.<br />
* Nimbleness. The safety enables significant changes to existing code to be made quickly and with confidence.<br />
* Expressiveness. It is powerful and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent package management and an extensive ecosystem.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A friendly and helpful community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating. (The new borrow checker released in Rust 1.31 helped greatly with this.)<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
Policy<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
<br />
Rust in Firefox docs<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Adding Rust code]<br />
* Writing Rust code<br />
** [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
** [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
** [https://crisal.io/words/2020/02/28/C++-rust-ffi-patterns-1-complex-data-structures.html FFI patterns #1 - Complex Rust data structures exposed seamlessly to C++]<br />
** [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Rust <--> C/C++ FFI for newbies]<br />
* Testing Rust code (TBA)<br />
<br />
Getting extra help<br />
* The Rust channel on [https://wiki.mozilla.org/Matrix Mozilla's Matrix network] contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Statistics ===<br />
<br />
* [https://docs.google.com/spreadsheets/d/1flUGg6Ut4bjtyWdyH_9emD9EAN01ljTAVft2S4Dq620/edit#gid=885787479 Lines of compiled Rust code shipped in Firefox (over time)]<br />
* [https://4e6.github.io/firefox-lang-stats/ Lines of Rust code in mozilla-central (current)]<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* libcubeb Audio backend for Linux (PulseAudio): {{bug|1346665}} (shipped in Firefox 59)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety assist productivity, and allow more aggressive optimizations.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* Profiler symbolication: {{bug|1509549}} (shipped in Firefox 67)<br />
** '''Why Rust?''' Makes use of existing crates that handle object file parsing and symbol iteration. Easy to compile to WebAssembly.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* [https://github.com/padenot/audio_thread_priority audio_thread_priority] {{bug|1429847}} (shipped in Firefox 69), allow promoting threads to a real-time scheduling class, on Windows/Linux/macOS.<br />
** '''Why Rust?''' This crate is being used by C++ code and by Rust code (audioipc), Rust is nicer to write than C++ (especially for what is essentially just a series of system calls, the error checking style is nice), and cbindgen made it trivial to expose a C ABI.<br />
* [https://github.com/mozilla/dogear/ Dogear] a bookmark merger for Sync. Shipped pref'd-off in {{bug|1482608}} (Firefox 68), enabled by default in {{bug|1588005}} (shipped in Firefox 72)<br />
** '''Why Rust?''' A single performant and safe implementation shared between desktop and the bookmarks engine in [https://github.com/mozilla/application-services/tree/master/components/places application-services]<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Replace libhyphen with mapped_hyph, {{bug|1590167}} (shipped in Firefox 72).<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}} (shipped in Firefox 76)<br />
** '''Why Rust?''' Performance and memory wins are substantial over previous JS implementation. It brings zero-copy parsing, and memory savvy resolving of localization strings. It also paves the way for migrating the rest of the Fluent APIs away from JS which is required for Fission.<br />
<br />
=== In progress ===<br />
<br />
* Port [https://github.com/projectfluent/fluent-rs Localization API] to Rust: {{bug|1613705}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend SmooshMonkey] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues. This also allows us to tailor the SDP parser specifically for the subset used in WebRTC, further reducing its surface area. It is currently run in parallel with the C parser in Nightly.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* libcubeb Audio backend for macOS (CoreAudio): {{bug|1530715}} (in Nightly since 70?)<br />
* [https://github.com/gfx-rs/wgpu wgpu], a [https://gpuweb.github.io/gpuweb/ WebGPU] API implementation: {{bug|webgpu-mvp}} (in Nightly since 72)<br />
** '''Why Rust?''' Complex tracking logic, wide attack area. Also, leverages Rust ecosystem for building libraries on top of our native implementation and the API that will target the Web.<br />
* Integrate the [https://github.com/mozilla/glean/ Glean SDK], a data collection library.<br />
<br />
=== Proposed ===<br />
<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
* [https://github.com/mozilla/application-services Sync/FxA components]<br />
** '''Why Rust?''' Single safe and performant implementation which is shared across all our products.<br />
* libcubeb Audio backend for Windows (WASAPI)<br />
* Replace the XML parser, possibly via c2rust: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
* Rewrite the ICE stack used by WebRTC; {{bug|1616966}}<br />
** '''Why Rust?''' Works with network data.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
** [https://github.com/mozilla/dump_syms/ dump_syms], a reimplementation of Google Breakpad's dump_syms tool for Windows. Used to parse PDB files and print out Breakpad-compatible symbol files. <br />
*** '''Why Rust?''' Doesn't rely on Microsoft closed-source libraries anymore, can be cross-compiled and run on a non-Windows host, is an order of magnitude faster, takes less than a third of the memory, produces better symbols and relies on an active and friendly upstream [https://github.com/getsentry/symbolic/ symbolic]<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/components various sync-related components used on iOS and Fenix], includes a cross-compiled FxA Rust client, and storage/syncing of bookmarks, history, logins, tabs and webextensions data.<br />
* [https://github.com/mozilla/fix-stacks/ fix-stacks], a stack frame symbolizer: {{bug|1596292}}<br />
** '''Why Rust?''' High performance needed, a single implementation can replace multiple platform-specific scripts, and we can use the [https://github.com/getsentry/symbolic/ symbolic] crate to do all the hard parts.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* [https://docs.google.com/document/d/16FgQPRxNb-Z6sfJy_P7edXzMVWE86jJEZVbmV0oC-m0/ 2020 Questionnaire results]<br />
* [https://docs.google.com/document/d/1puZvhWaURtViz8OC0HkB0h2dqJThVyAgLGFbIQpd4fo/ Oxidation 2020 Plan]<br />
<br />
= Meetings =<br />
<br />
* Berlin, January 2020 (minutes lost due to technical issues, unfortunately)<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1228419Oxidation2020-06-24T05:38:37Z<p>Nnethercote: /* FAQ */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more productive to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety. Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
* High performance. In particular, the safety enables code that is designed more actively for performance, especially parallel performance.<br />
* Nimbleness. The safety enables significant changes to existing code to be made quickly and with confidence.<br />
* Expressiveness. It is powerful and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent package management and an extensive ecosystem.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A friendly and helpful community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating. (The new borrow checker released in Rust 1.31 helped greatly with this.)<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
Policy<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
<br />
Writing code<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* [https://crisal.io/words/2020/02/28/C++-rust-ffi-patterns-1-complex-data-structures.html FFI patterns #1 - Complex Rust data structures exposed seamlessly to C++]<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Rust <--> C/C++ FFI for newbies]<br />
<br />
Getting help<br />
* The Rust channel on [https://wiki.mozilla.org/Matrix Mozilla's Matrix network] contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Statistics ===<br />
<br />
* [https://docs.google.com/spreadsheets/d/1flUGg6Ut4bjtyWdyH_9emD9EAN01ljTAVft2S4Dq620/edit#gid=885787479 Lines of compiled Rust code shipped in Firefox (over time)]<br />
* [https://4e6.github.io/firefox-lang-stats/ Lines of Rust code in mozilla-central (current)]<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* libcubeb Audio backend for Linux (PulseAudio): {{bug|1346665}} (shipped in Firefox 59)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety assist productivity, and allow more aggressive optimizations.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* Profiler symbolication: {{bug|1509549}} (shipped in Firefox 67)<br />
** '''Why Rust?''' Makes use of existing crates that handle object file parsing and symbol iteration. Easy to compile to WebAssembly.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* [https://github.com/padenot/audio_thread_priority audio_thread_priority] {{bug|1429847}} (shipped in Firefox 69), allow promoting threads to a real-time scheduling class, on Windows/Linux/macOS.<br />
** '''Why Rust?''' This crate is being used by C++ code and by Rust code (audioipc), Rust is nicer to write than C++ (especially for what is essentially just a series of system calls, the error checking style is nice), and cbindgen made it trivial to expose a C ABI.<br />
* [https://github.com/mozilla/dogear/ Dogear] a bookmark merger for Sync. Shipped pref'd-off in {{bug|1482608}} (Firefox 68), enabled by default in {{bug|1588005}} (shipped in Firefox 72)<br />
** '''Why Rust?''' A single performant and safe implementation shared between desktop and the bookmarks engine in [https://github.com/mozilla/application-services/tree/master/components/places application-services]<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Replace libhyphen with mapped_hyph, {{bug|1590167}} (shipped in Firefox 72).<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}} (shipped in Firefox 76)<br />
** '''Why Rust?''' Performance and memory wins are substantial over previous JS implementation. It brings zero-copy parsing, and memory savvy resolving of localization strings. It also paves the way for migrating the rest of the Fluent APIs away from JS which is required for Fission.<br />
<br />
=== In progress ===<br />
<br />
* Port [https://github.com/projectfluent/fluent-rs Localization API] to Rust: {{bug|1613705}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend SmooshMonkey] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues. This also allows us to tailor the SDP parser specifically for the subset used in WebRTC, further reducing its surface area. It is currently run in parallel with the C parser in Nightly.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* libcubeb Audio backend for macOS (CoreAudio): {{bug|1530715}} (in Nightly since 70?)<br />
* [https://github.com/gfx-rs/wgpu wgpu], a [https://gpuweb.github.io/gpuweb/ WebGPU] API implementation: {{bug|webgpu-mvp}} (in Nightly since 72)<br />
** '''Why Rust?''' Complex tracking logic, wide attack area. Also, leverages Rust ecosystem for building libraries on top of our native implementation and the API that will target the Web.<br />
* Integrate the [https://github.com/mozilla/glean/ Glean SDK], a data collection library.<br />
<br />
=== Proposed ===<br />
<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
* [https://github.com/mozilla/application-services Sync/FxA components]<br />
** '''Why Rust?''' Single safe and performant implementation which is shared across all our products.<br />
* libcubeb Audio backend for Windows (WASAPI)<br />
* Replace the XML parser, possibly via c2rust: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
* Rewrite the ICE stack used by WebRTC; {{bug|1616966}}<br />
** '''Why Rust?''' Works with network data.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
** [https://github.com/mozilla/dump_syms/ dump_syms], a reimplementation of Google Breakpad's dump_syms tool for Windows. Used to parse PDB files and print out Breakpad-compatible symbol files. <br />
*** '''Why Rust?''' Doesn't rely on Microsoft closed-source libraries anymore, can be cross-compiled and run on a non-Windows host, is an order of magnitude faster, takes less than a third of the memory, produces better symbols and relies on an active and friendly upstream [https://github.com/getsentry/symbolic/ symbolic]<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/components various sync-related components used on iOS and Fenix], includes a cross-compiled FxA Rust client, and storage/syncing of bookmarks, history, logins, tabs and webextensions data.<br />
* [https://github.com/mozilla/fix-stacks/ fix-stacks], a stack frame symbolizer: {{bug|1596292}}<br />
** '''Why Rust?''' High performance needed, a single implementation can replace multiple platform-specific scripts, and we can use the [https://github.com/getsentry/symbolic/ symbolic] crate to do all the hard parts.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* [https://docs.google.com/document/d/16FgQPRxNb-Z6sfJy_P7edXzMVWE86jJEZVbmV0oC-m0/ 2020 Questionnaire results]<br />
* [https://docs.google.com/document/d/1puZvhWaURtViz8OC0HkB0h2dqJThVyAgLGFbIQpd4fo/ Oxidation 2020 Plan]<br />
<br />
= Meetings =<br />
<br />
* Berlin, January 2020 (minutes lost due to technical issues, unfortunately)<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1228227Oxidation2020-06-18T06:25:51Z<p>Nnethercote: /* Blockers and obstacles */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more productive to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety. Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
* High performance. In particular, the safety enables code that is designed more actively for performance, especially parallel performance.<br />
* Nimbleness. The safety enables significant changes to existing code to be made quickly and with confidence.<br />
* Expressiveness. It is powerful and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent package management and an extensive ecosystem.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A friendly and helpful community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating. (The new borrow checker released in Rust 1.31 helped greatly with this.)<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
Policy<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
<br />
Writing code<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* [https://crisal.io/words/2020/02/28/C++-rust-ffi-patterns-1-complex-data-structures.html FFI patterns #1 - Complex Rust data structures exposed seamlessly to C++]<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Rust <--> C/C++ FFI for newbies]<br />
<br />
Getting help<br />
* The Rust channel on [https://wiki.mozilla.org/Matrix Mozilla's Matrix network] contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Statistics ===<br />
<br />
* [https://docs.google.com/spreadsheets/d/1flUGg6Ut4bjtyWdyH_9emD9EAN01ljTAVft2S4Dq620/edit#gid=885787479 Lines of compiled Rust code shipped in Firefox (over time)]<br />
* [https://4e6.github.io/firefox-lang-stats/ Lines of Rust code in mozilla-central (current)]<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* libcubeb Audio backend for Linux (PulseAudio): {{bug|1346665}} (shipped in Firefox 59)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety assist productivity, and allow more aggressive optimizations.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* Profiler symbolication: {{bug|1509549}} (shipped in Firefox 67)<br />
** '''Why Rust?''' Makes use of existing crates that handle object file parsing and symbol iteration. Easy to compile to WebAssembly.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* [https://github.com/padenot/audio_thread_priority audio_thread_priority] {{bug|1429847}} (shipped in Firefox 69), allow promoting threads to a real-time scheduling class, on Windows/Linux/macOS.<br />
** '''Why Rust?''' This crate is being used by C++ code and by Rust code (audioipc), Rust is nicer to write than C++ (especially for what is essentially just a series of system calls, the error checking style is nice), and cbindgen made it trivial to expose a C ABI.<br />
* [https://github.com/mozilla/dogear/ Dogear] a bookmark merger for Sync. Shipped pref'd-off in {{bug|1482608}} (Firefox 68), enabled by default in {{bug|1588005}} (shipped in Firefox 72)<br />
** '''Why Rust?''' A single performant and safe implementation shared between desktop and the bookmarks engine in [https://github.com/mozilla/application-services/tree/master/components/places application-services]<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Replace libhyphen with mapped_hyph, {{bug|1590167}} (shipped in Firefox 72).<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}} (shipped in Firefox 76)<br />
** '''Why Rust?''' Performance and memory wins are substantial over previous JS implementation. It brings zero-copy parsing, and memory savvy resolving of localization strings. It also paves the way for migrating the rest of the Fluent APIs away from JS which is required for Fission.<br />
<br />
=== In progress ===<br />
<br />
* Port [https://github.com/projectfluent/fluent-rs Localization API] to Rust: {{bug|1613705}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend SmooshMonkey] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues. This also allows us to tailor the SDP parser specifically for the subset used in WebRTC, further reducing its surface area. It is currently run in parallel with the C parser in Nightly.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* libcubeb Audio backend for macOS (CoreAudio): {{bug|1530715}} (in Nightly since 70?)<br />
* [https://github.com/gfx-rs/wgpu wgpu], a [https://gpuweb.github.io/gpuweb/ WebGPU] API implementation: {{bug|webgpu-mvp}} (in Nightly since 72)<br />
** '''Why Rust?''' Complex tracking logic, wide attack area. Also, leverages Rust ecosystem for building libraries on top of our native implementation and the API that will target the Web.<br />
* Integrate the [https://github.com/mozilla/glean/ Glean SDK], a data collection library.<br />
<br />
=== Proposed ===<br />
<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
* [https://github.com/mozilla/application-services Sync/FxA components]<br />
** '''Why Rust?''' Single safe and performant implementation which is shared across all our products.<br />
* libcubeb Audio backend for Windows (WASAPI)<br />
* Replace the XML parser, possibly via c2rust: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
* Rewrite the ICE stack used by WebRTC; {{bug|1616966}}<br />
** '''Why Rust?''' Works with network data.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
** [https://github.com/mozilla/dump_syms/ dump_syms], a reimplementation of Google Breakpad's dump_syms tool for Windows. Used to parse PDB files and print out Breakpad-compatible symbol files. <br />
*** '''Why Rust?''' Doesn't rely on Microsoft closed-source libraries anymore, can be cross-compiled and run on a non-Windows host, is an order of magnitude faster, takes less than a third of the memory, produces better symbols and relies on an active and friendly upstream [https://github.com/getsentry/symbolic/ symbolic]<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/components various sync-related components used on iOS and Fenix], includes a cross-compiled FxA Rust client, and storage/syncing of bookmarks, history, logins, tabs and webextensions data.<br />
* [https://github.com/mozilla/fix-stacks/ fix-stacks], a stack frame symbolizer: {{bug|1596292}}<br />
** '''Why Rust?''' High performance needed, a single implementation can replace multiple platform-specific scripts, and we can use the [https://github.com/getsentry/symbolic/ symbolic] crate to do all the hard parts.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* [https://docs.google.com/document/d/16FgQPRxNb-Z6sfJy_P7edXzMVWE86jJEZVbmV0oC-m0/ 2020 Questionnaire results]<br />
* [https://docs.google.com/document/d/1puZvhWaURtViz8OC0HkB0h2dqJThVyAgLGFbIQpd4fo/ Oxidation 2020 Plan]<br />
<br />
= Meetings =<br />
<br />
* Berlin, January 2020 (minutes lost due to technical issues, unfortunately)<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1228226Oxidation2020-06-18T06:24:10Z<p>Nnethercote: /* Blockers and obstacles */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more productive to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety. Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
* High performance. In particular, the safety enables code that is designed more actively for performance, especially parallel performance.<br />
* Nimbleness. The safety enables significant changes to existing code to be made quickly and with confidence.<br />
* Expressiveness. It is powerful and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent package management and an extensive ecosystem.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A friendly and helpful community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating. (The new borrow checker released in Rust 1.31 helped greatly with this.)<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
Policy<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
<br />
Writing code<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* [https://crisal.io/words/2020/02/28/C++-rust-ffi-patterns-1-complex-data-structures.html FFI patterns #1 - Complex Rust data structures exposed seamlessly to C++]<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Rust <--> C/C++ FFI for newbies]<br />
<br />
Getting help<br />
* The Rust channel on [https://wiki.mozilla.org/Matrix Mozilla's Matrix network] contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Statistics ===<br />
<br />
* [https://docs.google.com/spreadsheets/d/1flUGg6Ut4bjtyWdyH_9emD9EAN01ljTAVft2S4Dq620/edit#gid=885787479 Lines of compiled Rust code shipped in Firefox (over time)]<br />
* [https://4e6.github.io/firefox-lang-stats/ Lines of Rust code in mozilla-central (current)]<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* libcubeb Audio backend for Linux (PulseAudio): {{bug|1346665}} (shipped in Firefox 59)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety assist productivity, and allow more aggressive optimizations.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* Profiler symbolication: {{bug|1509549}} (shipped in Firefox 67)<br />
** '''Why Rust?''' Makes use of existing crates that handle object file parsing and symbol iteration. Easy to compile to WebAssembly.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* [https://github.com/padenot/audio_thread_priority audio_thread_priority] {{bug|1429847}} (shipped in Firefox 69), allow promoting threads to a real-time scheduling class, on Windows/Linux/macOS.<br />
** '''Why Rust?''' This crate is being used by C++ code and by Rust code (audioipc), Rust is nicer to write than C++ (especially for what is essentially just a series of system calls, the error checking style is nice), and cbindgen made it trivial to expose a C ABI.<br />
* [https://github.com/mozilla/dogear/ Dogear] a bookmark merger for Sync. Shipped pref'd-off in {{bug|1482608}} (Firefox 68), enabled by default in {{bug|1588005}} (shipped in Firefox 72)<br />
** '''Why Rust?''' A single performant and safe implementation shared between desktop and the bookmarks engine in [https://github.com/mozilla/application-services/tree/master/components/places application-services]<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Replace libhyphen with mapped_hyph, {{bug|1590167}} (shipped in Firefox 72).<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}} (shipped in Firefox 76)<br />
** '''Why Rust?''' Performance and memory wins are substantial over previous JS implementation. It brings zero-copy parsing, and memory savvy resolving of localization strings. It also paves the way for migrating the rest of the Fluent APIs away from JS which is required for Fission.<br />
<br />
=== In progress ===<br />
<br />
* Port [https://github.com/projectfluent/fluent-rs Localization API] to Rust: {{bug|1613705}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend SmooshMonkey] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues. This also allows us to tailor the SDP parser specifically for the subset used in WebRTC, further reducing its surface area. It is currently run in parallel with the C parser in Nightly.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* libcubeb Audio backend for macOS (CoreAudio): {{bug|1530715}} (in Nightly since 70?)<br />
* [https://github.com/gfx-rs/wgpu wgpu], a [https://gpuweb.github.io/gpuweb/ WebGPU] API implementation: {{bug|webgpu-mvp}} (in Nightly since 72)<br />
** '''Why Rust?''' Complex tracking logic, wide attack area. Also, leverages Rust ecosystem for building libraries on top of our native implementation and the API that will target the Web.<br />
* Integrate the [https://github.com/mozilla/glean/ Glean SDK], a data collection library.<br />
<br />
=== Proposed ===<br />
<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
* [https://github.com/mozilla/application-services Sync/FxA components]<br />
** '''Why Rust?''' Single safe and performant implementation which is shared across all our products.<br />
* libcubeb Audio backend for Windows (WASAPI)<br />
* Replace the XML parser, possibly via c2rust: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
* Rewrite the ICE stack used by WebRTC; {{bug|1616966}}<br />
** '''Why Rust?''' Works with network data.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
** [https://github.com/mozilla/dump_syms/ dump_syms], a reimplementation of Google Breakpad's dump_syms tool for Windows. Used to parse PDB files and print out Breakpad-compatible symbol files. <br />
*** '''Why Rust?''' Doesn't rely on Microsoft closed-source libraries anymore, can be cross-compiled and run on a non-Windows host, is an order of magnitude faster, takes less than a third of the memory, produces better symbols and relies on an active and friendly upstream [https://github.com/getsentry/symbolic/ symbolic]<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/components various sync-related components used on iOS and Fenix], includes a cross-compiled FxA Rust client, and storage/syncing of bookmarks, history, logins, tabs and webextensions data.<br />
* [https://github.com/mozilla/fix-stacks/ fix-stacks], a stack frame symbolizer: {{bug|1596292}}<br />
** '''Why Rust?''' High performance needed, a single implementation can replace multiple platform-specific scripts, and we can use the [https://github.com/getsentry/symbolic/ symbolic] crate to do all the hard parts.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* [https://docs.google.com/document/d/1puZvhWaURtViz8OC0HkB0h2dqJThVyAgLGFbIQpd4fo/ Oxidation 2020 Plan]<br />
<br />
= Meetings =<br />
<br />
* Berlin, January 2020 (minutes lost due to technical issues, unfortunately)<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1228225Oxidation2020-06-18T06:18:23Z<p>Nnethercote: /* Rust in Firefox */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more productive to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety. Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
* High performance. In particular, the safety enables code that is designed more actively for performance, especially parallel performance.<br />
* Nimbleness. The safety enables significant changes to existing code to be made quickly and with confidence.<br />
* Expressiveness. It is powerful and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent package management and an extensive ecosystem.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A friendly and helpful community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating. (The new borrow checker released in Rust 1.31 helped greatly with this.)<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
Policy<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
<br />
Writing code<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* [https://crisal.io/words/2020/02/28/C++-rust-ffi-patterns-1-complex-data-structures.html FFI patterns #1 - Complex Rust data structures exposed seamlessly to C++]<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Rust <--> C/C++ FFI for newbies]<br />
<br />
Getting help<br />
* The Rust channel on [https://wiki.mozilla.org/Matrix Mozilla's Matrix network] contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Statistics ===<br />
<br />
* [https://docs.google.com/spreadsheets/d/1flUGg6Ut4bjtyWdyH_9emD9EAN01ljTAVft2S4Dq620/edit#gid=885787479 Lines of compiled Rust code shipped in Firefox (over time)]<br />
* [https://4e6.github.io/firefox-lang-stats/ Lines of Rust code in mozilla-central (current)]<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* libcubeb Audio backend for Linux (PulseAudio): {{bug|1346665}} (shipped in Firefox 59)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety assist productivity, and allow more aggressive optimizations.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* Profiler symbolication: {{bug|1509549}} (shipped in Firefox 67)<br />
** '''Why Rust?''' Makes use of existing crates that handle object file parsing and symbol iteration. Easy to compile to WebAssembly.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* [https://github.com/padenot/audio_thread_priority audio_thread_priority] {{bug|1429847}} (shipped in Firefox 69), allow promoting threads to a real-time scheduling class, on Windows/Linux/macOS.<br />
** '''Why Rust?''' This crate is being used by C++ code and by Rust code (audioipc), Rust is nicer to write than C++ (especially for what is essentially just a series of system calls, the error checking style is nice), and cbindgen made it trivial to expose a C ABI.<br />
* [https://github.com/mozilla/dogear/ Dogear] a bookmark merger for Sync. Shipped pref'd-off in {{bug|1482608}} (Firefox 68), enabled by default in {{bug|1588005}} (shipped in Firefox 72)<br />
** '''Why Rust?''' A single performant and safe implementation shared between desktop and the bookmarks engine in [https://github.com/mozilla/application-services/tree/master/components/places application-services]<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Replace libhyphen with mapped_hyph, {{bug|1590167}} (shipped in Firefox 72).<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}} (shipped in Firefox 76)<br />
** '''Why Rust?''' Performance and memory wins are substantial over previous JS implementation. It brings zero-copy parsing, and memory savvy resolving of localization strings. It also paves the way for migrating the rest of the Fluent APIs away from JS which is required for Fission.<br />
<br />
=== In progress ===<br />
<br />
* Port [https://github.com/projectfluent/fluent-rs Localization API] to Rust: {{bug|1613705}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend SmooshMonkey] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues. This also allows us to tailor the SDP parser specifically for the subset used in WebRTC, further reducing its surface area. It is currently run in parallel with the C parser in Nightly.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* libcubeb Audio backend for macOS (CoreAudio): {{bug|1530715}} (in Nightly since 70?)<br />
* [https://github.com/gfx-rs/wgpu wgpu], a [https://gpuweb.github.io/gpuweb/ WebGPU] API implementation: {{bug|webgpu-mvp}} (in Nightly since 72)<br />
** '''Why Rust?''' Complex tracking logic, wide attack area. Also, leverages Rust ecosystem for building libraries on top of our native implementation and the API that will target the Web.<br />
* Integrate the [https://github.com/mozilla/glean/ Glean SDK], a data collection library.<br />
<br />
=== Proposed ===<br />
<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
* [https://github.com/mozilla/application-services Sync/FxA components]<br />
** '''Why Rust?''' Single safe and performant implementation which is shared across all our products.<br />
* libcubeb Audio backend for Windows (WASAPI)<br />
* Replace the XML parser, possibly via c2rust: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
* Rewrite the ICE stack used by WebRTC; {{bug|1616966}}<br />
** '''Why Rust?''' Works with network data.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
** [https://github.com/mozilla/dump_syms/ dump_syms], a reimplementation of Google Breakpad's dump_syms tool for Windows. Used to parse PDB files and print out Breakpad-compatible symbol files. <br />
*** '''Why Rust?''' Doesn't rely on Microsoft closed-source libraries anymore, can be cross-compiled and run on a non-Windows host, is an order of magnitude faster, takes less than a third of the memory, produces better symbols and relies on an active and friendly upstream [https://github.com/getsentry/symbolic/ symbolic]<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/components various sync-related components used on iOS and Fenix], includes a cross-compiled FxA Rust client, and storage/syncing of bookmarks, history, logins, tabs and webextensions data.<br />
* [https://github.com/mozilla/fix-stacks/ fix-stacks], a stack frame symbolizer: {{bug|1596292}}<br />
** '''Why Rust?''' High performance needed, a single implementation can replace multiple platform-specific scripts, and we can use the [https://github.com/getsentry/symbolic/ symbolic] crate to do all the hard parts.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* Berlin, January 2020 (minutes lost due to technical issues, unfortunately)<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1228224Oxidation2020-06-18T06:17:53Z<p>Nnethercote: /* Rust in Firefox */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more productive to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety. Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
* High performance. In particular, the safety enables code that is designed more actively for performance, especially parallel performance.<br />
* Nimbleness. The safety enables significant changes to existing code to be made quickly and with confidence.<br />
* Expressiveness. It is powerful and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent package management and an extensive ecosystem.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A friendly and helpful community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating. (The new borrow checker released in Rust 1.31 helped greatly with this.)<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
Policy<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
<br />
Writing code<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* [https://crisal.io/words/2020/02/28/C++-rust-ffi-patterns-1-complex-data-structures.html FFI patterns #1 - Complex Rust data structures exposed seamlessly to C++]<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Rust <--> C/C++ FFI for newbies]<br />
<br />
Getting help<br />
* The Rust channel on [https://wiki.mozilla.org/Matrix Mozilla's Matrix network] contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Statistics ===<br />
<br />
* [https://docs.google.com/spreadsheets/d/1flUGg6Ut4bjtyWdyH_9emD9EAN01ljTAVft2S4Dq620/edit#gid=885787479 Lines of compiled Rust code shipped in Firefox (over time)]<br />
* [https://4e6.github.io/firefox-lang-stats/ Lines of Rust code in mozilla-central (current)]<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* libcubeb Audio backend for Linux (PulseAudio): {{bug|1346665}} (shipped in Firefox 59)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety assist productivity, and allow more aggressive optimizations.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* Profiler symbolication: {{bug|1509549}} (shipped in Firefox 67)<br />
** '''Why Rust?''' Makes use of existing crates that handle object file parsing and symbol iteration. Easy to compile to WebAssembly.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* [https://github.com/padenot/audio_thread_priority audio_thread_priority] {{bug|1429847}} (shipped in Firefox 69), allow promoting threads to a real-time scheduling class, on Windows/Linux/macOS.<br />
** '''Why Rust?''' This crate is being used by C++ code and by Rust code (audioipc), Rust is nicer to write than C++ (especially for what is essentially just a series of system calls, the error checking style is nice), and cbindgen made it trivial to expose a C ABI.<br />
* [https://github.com/mozilla/dogear/ Dogear] a bookmark merger for Sync. Shipped pref'd-off in {{bug|1482608}} (Firefox 68), enabled by default in {{bug|1588005}} (shipped in Firefox 72)<br />
** '''Why Rust?''' A single performant and safe implementation shared between desktop and the bookmarks engine in [https://github.com/mozilla/application-services/tree/master/components/places application-services]<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Replace libhyphen with mapped_hyph, {{bug|1590167}} (shipped in Firefox 72).<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}} (shipped in Firefox 76)<br />
** '''Why Rust?''' Performance and memory wins are substantial over previous JS implementation. It brings zero-copy parsing, and memory savvy resolving of localization strings. It also paves the way for migrating the rest of the Fluent APIs away from JS which is required for Fission.<br />
<br />
=== In progress ===<br />
<br />
* Port [https://github.com/projectfluent/fluent-rs Localization API] to Rust: {{bug|1613705}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend SmooshMonkey] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues. This also allows us to tailor the SDP parser specifically for the subset used in WebRTC, further reducing its surface area. It is currently run in parallel with the C parser in Nightly.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* libcubeb Audio backend for macOS (CoreAudio): {{bug|1530715}} (in Nightly since 70?)<br />
* [https://github.com/gfx-rs/wgpu wgpu], a [https://gpuweb.github.io/gpuweb/ WebGPU] API implementation: {{bug|webgpu-mvp}} (in Nightly since 72)<br />
** '''Why Rust?''' Complex tracking logic, wide attack area. Also, leverages Rust ecosystem for building libraries on top of our native implementation and the API that will target the Web.<br />
* Integrate the [https://github.com/mozilla/glean/ Glean SDK], a data collection library.<br />
<br />
=== Proposed ===<br />
<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
* [https://github.com/mozilla/application-services Sync/FxA components]<br />
** '''Why Rust?''' Single safe and performant implementation which is shared across all our products.<br />
* libcubeb Audio backend for Windows (WASAPI)<br />
* Replace the XML parser, possibly via c2rust: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
* Rewrite the ICE stack used by WebRTC; {{bug|1616966}}<br />
** '''Why Rust?''' Works with network data.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
** [https://github.com/mozilla/dump_syms/ dump_syms], a reimplementation of Google Breakpad's dump_syms tool for Windows. Used to parse PDB files and print out Breakpad-compatible symbol files. <br />
*** '''Why Rust?''' Doesn't rely on Microsoft closed-source libraries anymore, can be cross-compiled and run on a non-Windows host, is an order of magnitude faster, takes less than a third of the memory, produces better symbols and relies on an active and friendly upstream [https://github.com/getsentry/symbolic/ symbolic]<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/components various sync-related components used on iOS and Fenix], includes a cross-compiled FxA Rust client, and storage/syncing of bookmarks, history, logins, tabs and webextensions data.<br />
* [https://github.com/mozilla/fix-stacks/ fix-stacks], a stack frame symbolizer: {{bug|1596292}}<br />
** '''Why Rust?''' High performance needed, a single implementation can replace multiple platform-specific scripts, and we can use the [https://github.com/getsentry/symbolic/ symbolic] crate to do all the hard parts.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* Berlin, January 2020 (minutes lost due to technical issues, unfortunately)<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1228222Oxidation2020-06-18T04:39:09Z<p>Nnethercote: /* FAQ */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more productive to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety. Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
* High performance. In particular, the safety enables code that is designed more actively for performance, especially parallel performance.<br />
* Nimbleness. The safety enables significant changes to existing code to be made quickly and with confidence.<br />
* Expressiveness. It is powerful and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent package management and an extensive ecosystem.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A friendly and helpful community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating. (The new borrow checker released in Rust 1.31 helped greatly with this.)<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
Policy<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
<br />
Writing code<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* [https://crisal.io/words/2020/02/28/C++-rust-ffi-patterns-1-complex-data-structures.html FFI patterns #1 - Complex Rust data structures exposed seamlessly to C++]<br />
<br />
Getting help<br />
* The Rust channel on [https://wiki.mozilla.org/Matrix Mozilla's Matrix network] contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Statistics ===<br />
<br />
* [https://docs.google.com/spreadsheets/d/1flUGg6Ut4bjtyWdyH_9emD9EAN01ljTAVft2S4Dq620/edit#gid=885787479 Lines of compiled Rust code shipped in Firefox (over time)]<br />
* [https://4e6.github.io/firefox-lang-stats/ Lines of Rust code in mozilla-central (current)]<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* libcubeb Audio backend for Linux (PulseAudio): {{bug|1346665}} (shipped in Firefox 59)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety assist productivity, and allow more aggressive optimizations.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* Profiler symbolication: {{bug|1509549}} (shipped in Firefox 67)<br />
** '''Why Rust?''' Makes use of existing crates that handle object file parsing and symbol iteration. Easy to compile to WebAssembly.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* [https://github.com/padenot/audio_thread_priority audio_thread_priority] {{bug|1429847}} (shipped in Firefox 69), allow promoting threads to a real-time scheduling class, on Windows/Linux/macOS.<br />
** '''Why Rust?''' This crate is being used by C++ code and by Rust code (audioipc), Rust is nicer to write than C++ (especially for what is essentially just a series of system calls, the error checking style is nice), and cbindgen made it trivial to expose a C ABI.<br />
* [https://github.com/mozilla/dogear/ Dogear] a bookmark merger for Sync. Shipped pref'd-off in {{bug|1482608}} (Firefox 68), enabled by default in {{bug|1588005}} (shipped in Firefox 72)<br />
** '''Why Rust?''' A single performant and safe implementation shared between desktop and the bookmarks engine in [https://github.com/mozilla/application-services/tree/master/components/places application-services]<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Replace libhyphen with mapped_hyph, {{bug|1590167}} (shipped in Firefox 72).<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}} (shipped in Firefox 76)<br />
** '''Why Rust?''' Performance and memory wins are substantial over previous JS implementation. It brings zero-copy parsing, and memory savvy resolving of localization strings. It also paves the way for migrating the rest of the Fluent APIs away from JS which is required for Fission.<br />
<br />
=== In progress ===<br />
<br />
* Port [https://github.com/projectfluent/fluent-rs Localization API] to Rust: {{bug|1613705}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend SmooshMonkey] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues. This also allows us to tailor the SDP parser specifically for the subset used in WebRTC, further reducing its surface area. It is currently run in parallel with the C parser in Nightly.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* libcubeb Audio backend for macOS (CoreAudio): {{bug|1530715}} (in Nightly since 70?)<br />
* [https://github.com/gfx-rs/wgpu wgpu], a [https://gpuweb.github.io/gpuweb/ WebGPU] API implementation: {{bug|webgpu-mvp}} (in Nightly since 72)<br />
** '''Why Rust?''' Complex tracking logic, wide attack area. Also, leverages Rust ecosystem for building libraries on top of our native implementation and the API that will target the Web.<br />
* Integrate the [https://github.com/mozilla/glean/ Glean SDK], a data collection library.<br />
<br />
=== Proposed ===<br />
<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
* [https://github.com/mozilla/application-services Sync/FxA components]<br />
** '''Why Rust?''' Single safe and performant implementation which is shared across all our products.<br />
* libcubeb Audio backend for Windows (WASAPI)<br />
* Replace the XML parser, possibly via c2rust: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
* Rewrite the ICE stack used by WebRTC; {{bug|1616966}}<br />
** '''Why Rust?''' Works with network data.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
** [https://github.com/mozilla/dump_syms/ dump_syms], a reimplementation of Google Breakpad's dump_syms tool for Windows. Used to parse PDB files and print out Breakpad-compatible symbol files. <br />
*** '''Why Rust?''' Doesn't rely on Microsoft closed-source libraries anymore, can be cross-compiled and run on a non-Windows host, is an order of magnitude faster, takes less than a third of the memory, produces better symbols and relies on an active and friendly upstream [https://github.com/getsentry/symbolic/ symbolic]<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/components various sync-related components used on iOS and Fenix], includes a cross-compiled FxA Rust client, and storage/syncing of bookmarks, history, logins, tabs and webextensions data.<br />
* [https://github.com/mozilla/fix-stacks/ fix-stacks], a stack frame symbolizer: {{bug|1596292}}<br />
** '''Why Rust?''' High performance needed, a single implementation can replace multiple platform-specific scripts, and we can use the [https://github.com/getsentry/symbolic/ symbolic] crate to do all the hard parts.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* Berlin, January 2020 (minutes lost due to technical issues, unfortunately)<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1228221Oxidation2020-06-18T04:31:06Z<p>Nnethercote: /* FAQ */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more productive to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety. Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
* High performance. In particular, the safety enables code that is designed more actively for performance, especially parallel performance.<br />
* Nimbleness. The safety enables significant changes to existing code to be made quickly and with confidence.<br />
* Expressiveness. It is powerful and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent package management and an extensive ecosystem.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A friendly and helpful community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating. (The new borrow checker released in Rust 1.31 helped greatly with this.)<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
Policy<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
<br />
Writing code<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* [https://crisal.io/words/2020/02/28/C++-rust-ffi-patterns-1-complex-data-structures.html FFI patterns #1 - Complex Rust data structures exposed seamlessly to C++]<br />
<br />
Getting help<br />
* The Rust channel on [https://wiki.mozilla.org/Matrix Mozilla's Matrix network] contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central?<br /><br />
<br />
'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.<br />
<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Statistics ===<br />
<br />
* [https://docs.google.com/spreadsheets/d/1flUGg6Ut4bjtyWdyH_9emD9EAN01ljTAVft2S4Dq620/edit#gid=885787479 Lines of compiled Rust code shipped in Firefox (over time)]<br />
* [https://4e6.github.io/firefox-lang-stats/ Lines of Rust code in mozilla-central (current)]<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* libcubeb Audio backend for Linux (PulseAudio): {{bug|1346665}} (shipped in Firefox 59)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety assist productivity, and allow more aggressive optimizations.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* Profiler symbolication: {{bug|1509549}} (shipped in Firefox 67)<br />
** '''Why Rust?''' Makes use of existing crates that handle object file parsing and symbol iteration. Easy to compile to WebAssembly.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* [https://github.com/padenot/audio_thread_priority audio_thread_priority] {{bug|1429847}} (shipped in Firefox 69), allow promoting threads to a real-time scheduling class, on Windows/Linux/macOS.<br />
** '''Why Rust?''' This crate is being used by C++ code and by Rust code (audioipc), Rust is nicer to write than C++ (especially for what is essentially just a series of system calls, the error checking style is nice), and cbindgen made it trivial to expose a C ABI.<br />
* [https://github.com/mozilla/dogear/ Dogear] a bookmark merger for Sync. Shipped pref'd-off in {{bug|1482608}} (Firefox 68), enabled by default in {{bug|1588005}} (shipped in Firefox 72)<br />
** '''Why Rust?''' A single performant and safe implementation shared between desktop and the bookmarks engine in [https://github.com/mozilla/application-services/tree/master/components/places application-services]<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Replace libhyphen with mapped_hyph, {{bug|1590167}} (shipped in Firefox 72).<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}} (shipped in Firefox 76)<br />
** '''Why Rust?''' Performance and memory wins are substantial over previous JS implementation. It brings zero-copy parsing, and memory savvy resolving of localization strings. It also paves the way for migrating the rest of the Fluent APIs away from JS which is required for Fission.<br />
<br />
=== In progress ===<br />
<br />
* Port [https://github.com/projectfluent/fluent-rs Localization API] to Rust: {{bug|1613705}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend SmooshMonkey] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues. This also allows us to tailor the SDP parser specifically for the subset used in WebRTC, further reducing its surface area. It is currently run in parallel with the C parser in Nightly.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* libcubeb Audio backend for macOS (CoreAudio): {{bug|1530715}} (in Nightly since 70?)<br />
* [https://github.com/gfx-rs/wgpu wgpu], a [https://gpuweb.github.io/gpuweb/ WebGPU] API implementation: {{bug|webgpu-mvp}} (in Nightly since 72)<br />
** '''Why Rust?''' Complex tracking logic, wide attack area. Also, leverages Rust ecosystem for building libraries on top of our native implementation and the API that will target the Web.<br />
* Integrate the [https://github.com/mozilla/glean/ Glean SDK], a data collection library.<br />
<br />
=== Proposed ===<br />
<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
* [https://github.com/mozilla/application-services Sync/FxA components]<br />
** '''Why Rust?''' Single safe and performant implementation which is shared across all our products.<br />
* libcubeb Audio backend for Windows (WASAPI)<br />
* Replace the XML parser, possibly via c2rust: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
* Rewrite the ICE stack used by WebRTC; {{bug|1616966}}<br />
** '''Why Rust?''' Works with network data.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
** [https://github.com/mozilla/dump_syms/ dump_syms], a reimplementation of Google Breakpad's dump_syms tool for Windows. Used to parse PDB files and print out Breakpad-compatible symbol files. <br />
*** '''Why Rust?''' Doesn't rely on Microsoft closed-source libraries anymore, can be cross-compiled and run on a non-Windows host, is an order of magnitude faster, takes less than a third of the memory, produces better symbols and relies on an active and friendly upstream [https://github.com/getsentry/symbolic/ symbolic]<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/components various sync-related components used on iOS and Fenix], includes a cross-compiled FxA Rust client, and storage/syncing of bookmarks, history, logins, tabs and webextensions data.<br />
* [https://github.com/mozilla/fix-stacks/ fix-stacks], a stack frame symbolizer: {{bug|1596292}}<br />
** '''Why Rust?''' High performance needed, a single implementation can replace multiple platform-specific scripts, and we can use the [https://github.com/getsentry/symbolic/ symbolic] crate to do all the hard parts.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* Berlin, January 2020 (minutes lost due to technical issues, unfortunately)<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1228179Oxidation2020-06-17T04:05:36Z<p>Nnethercote: /* Rust in Firefox */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more productive to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety. Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
* High performance. In particular, the safety enables code that is designed more actively for performance, especially parallel performance.<br />
* Nimbleness. The safety enables significant changes to existing code to be made quickly and with confidence.<br />
* Expressiveness. It is powerful and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent package management and an extensive ecosystem.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A friendly and helpful community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating. (The new borrow checker released in Rust 1.31 helped greatly with this.)<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
Policy<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
<br />
Writing code<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* [https://crisal.io/words/2020/02/28/C++-rust-ffi-patterns-1-complex-data-structures.html FFI patterns #1 - Complex Rust data structures exposed seamlessly to C++]<br />
<br />
Getting help<br />
* The Rust channel on [https://wiki.mozilla.org/Matrix Mozilla's Matrix network] contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central?<br /><br />
<br />
'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.<br />
<br />
<br />
'''Q:''' Do we support building standalone Rust programs?<br /><br />
<br />
'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.<br />
<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Statistics ===<br />
<br />
* [https://docs.google.com/spreadsheets/d/1flUGg6Ut4bjtyWdyH_9emD9EAN01ljTAVft2S4Dq620/edit#gid=885787479 Lines of compiled Rust code shipped in Firefox (over time)]<br />
* [https://4e6.github.io/firefox-lang-stats/ Lines of Rust code in mozilla-central (current)]<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* libcubeb Audio backend for Linux (PulseAudio): {{bug|1346665}} (shipped in Firefox 59)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety assist productivity, and allow more aggressive optimizations.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* Profiler symbolication: {{bug|1509549}} (shipped in Firefox 67)<br />
** '''Why Rust?''' Makes use of existing crates that handle object file parsing and symbol iteration. Easy to compile to WebAssembly.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* [https://github.com/padenot/audio_thread_priority audio_thread_priority] {{bug|1429847}} (shipped in Firefox 69), allow promoting threads to a real-time scheduling class, on Windows/Linux/macOS.<br />
** '''Why Rust?''' This crate is being used by C++ code and by Rust code (audioipc), Rust is nicer to write than C++ (especially for what is essentially just a series of system calls, the error checking style is nice), and cbindgen made it trivial to expose a C ABI.<br />
* [https://github.com/mozilla/dogear/ Dogear] a bookmark merger for Sync. Shipped pref'd-off in {{bug|1482608}} (Firefox 68), enabled by default in {{bug|1588005}} (shipped in Firefox 72)<br />
** '''Why Rust?''' A single performant and safe implementation shared between desktop and the bookmarks engine in [https://github.com/mozilla/application-services/tree/master/components/places application-services]<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Replace libhyphen with mapped_hyph, {{bug|1590167}} (shipped in Firefox 72).<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}} (shipped in Firefox 76)<br />
** '''Why Rust?''' Performance and memory wins are substantial over previous JS implementation. It brings zero-copy parsing, and memory savvy resolving of localization strings. It also paves the way for migrating the rest of the Fluent APIs away from JS which is required for Fission.<br />
<br />
=== In progress ===<br />
<br />
* Port [https://github.com/projectfluent/fluent-rs Localization API] to Rust: {{bug|1613705}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend SmooshMonkey] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues. This also allows us to tailor the SDP parser specifically for the subset used in WebRTC, further reducing its surface area. It is currently run in parallel with the C parser in Nightly.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* libcubeb Audio backend for macOS (CoreAudio): {{bug|1530715}} (in Nightly since 70?)<br />
* [https://github.com/gfx-rs/wgpu wgpu], a [https://gpuweb.github.io/gpuweb/ WebGPU] API implementation: {{bug|webgpu-mvp}} (in Nightly since 72)<br />
** '''Why Rust?''' Complex tracking logic, wide attack area. Also, leverages Rust ecosystem for building libraries on top of our native implementation and the API that will target the Web.<br />
* Integrate the [https://github.com/mozilla/glean/ Glean SDK], a data collection library.<br />
<br />
=== Proposed ===<br />
<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
* [https://github.com/mozilla/application-services Sync/FxA components]<br />
** '''Why Rust?''' Single safe and performant implementation which is shared across all our products.<br />
* libcubeb Audio backend for Windows (WASAPI)<br />
* Replace the XML parser, possibly via c2rust: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
* Rewrite the ICE stack used by WebRTC; {{bug|1616966}}<br />
** '''Why Rust?''' Works with network data.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
** [https://github.com/mozilla/dump_syms/ dump_syms], a reimplementation of Google Breakpad's dump_syms tool for Windows. Used to parse PDB files and print out Breakpad-compatible symbol files. <br />
*** '''Why Rust?''' Doesn't rely on Microsoft closed-source libraries anymore, can be cross-compiled and run on a non-Windows host, is an order of magnitude faster, takes less than a third of the memory, produces better symbols and relies on an active and friendly upstream [https://github.com/getsentry/symbolic/ symbolic]<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/components various sync-related components used on iOS and Fenix], includes a cross-compiled FxA Rust client, and storage/syncing of bookmarks, history, logins, tabs and webextensions data.<br />
* [https://github.com/mozilla/fix-stacks/ fix-stacks], a stack frame symbolizer: {{bug|1596292}}<br />
** '''Why Rust?''' High performance needed, a single implementation can replace multiple platform-specific scripts, and we can use the [https://github.com/getsentry/symbolic/ symbolic] crate to do all the hard parts.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* Berlin, January 2020 (minutes lost due to technical issues, unfortunately)<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1227381Oxidation2020-05-20T05:12:44Z<p>Nnethercote: /* Within Firefox */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more productive to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety. Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
* High performance. In particular, the safety enables code that is designed more actively for performance, especially parallel performance.<br />
* Nimbleness. The safety enables significant changes to existing code to be made quickly and with confidence.<br />
* Expressiveness. It is powerful and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent package management and an extensive ecosystem.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A friendly and helpful community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating. (The new borrow checker released in Rust 1.31 helped greatly with this.)<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* [https://crisal.io/words/2020/02/28/C++-rust-ffi-patterns-1-complex-data-structures.html FFI patterns #1 - Complex Rust data structures exposed seamlessly to C++]<br />
* The Rust channel on [https://wiki.mozilla.org/Matrix Mozilla's Matrix network] contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central?<br /><br />
<br />
'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.<br />
<br />
<br />
'''Q:''' Do we support building standalone Rust programs?<br /><br />
<br />
'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.<br />
<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Statistics ===<br />
<br />
* [https://docs.google.com/spreadsheets/d/1flUGg6Ut4bjtyWdyH_9emD9EAN01ljTAVft2S4Dq620/edit#gid=885787479 Lines of compiled Rust code shipped in Firefox (over time)]<br />
* [https://4e6.github.io/firefox-lang-stats/ Lines of Rust code in mozilla-central (current)]<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* libcubeb Audio backend for Linux (PulseAudio): {{bug|1346665}} (shipped in Firefox 59)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety assist productivity, and allow more aggressive optimizations.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* Profiler symbolication: {{bug|1509549}} (shipped in Firefox 67)<br />
** '''Why Rust?''' Makes use of existing crates that handle object file parsing and symbol iteration. Easy to compile to WebAssembly.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* [https://github.com/padenot/audio_thread_priority audio_thread_priority] {{bug|1429847}} (shipped in Firefox 69), allow promoting threads to a real-time scheduling class, on Windows/Linux/macOS.<br />
** '''Why Rust?''' This crate is being used by C++ code and by Rust code (audioipc), Rust is nicer to write than C++ (especially for what is essentially just a series of system calls, the error checking style is nice), and cbindgen made it trivial to expose a C ABI.<br />
* [https://github.com/mozilla/dogear/ Dogear] a bookmark merger for Sync. Shipped pref'd-off in {{bug|1482608}} (Firefox 68), enabled by default in {{bug|1588005}} (shipped in Firefox 72)<br />
** '''Why Rust?''' A single performant and safe implementation shared between desktop and the bookmarks engine in [https://github.com/mozilla/application-services/tree/master/components/places application-services]<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Replace libhyphen with mapped_hyph, {{bug|1590167}} (shipped in Firefox 72).<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}} (shipped in Firefox 76)<br />
** '''Why Rust?''' Performance and memory wins are substantial over previous JS implementation. It brings zero-copy parsing, and memory savvy resolving of localization strings. It also paves the way for migrating the rest of the Fluent APIs away from JS which is required for Fission.<br />
<br />
=== In progress ===<br />
<br />
* Port [https://github.com/projectfluent/fluent-rs Localization API] to Rust: {{bug|1613705}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend SmooshMonkey] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues. This also allows us to tailor the SDP parser specifically for the subset used in WebRTC, further reducing its surface area. It is currently run in parallel with the C parser in Nightly.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* libcubeb Audio backend for macOS (CoreAudio): {{bug|1530715}} (in Nightly since 70?)<br />
* [https://github.com/gfx-rs/wgpu wgpu], a [https://gpuweb.github.io/gpuweb/ WebGPU] API implementation: {{bug|webgpu-mvp}} (in Nightly since 72)<br />
** '''Why Rust?''' Complex tracking logic, wide attack area. Also, leverages Rust ecosystem for building libraries on top of our native implementation and the API that will target the Web.<br />
* Integrate the [https://github.com/mozilla/glean/ Glean SDK], a data collection library.<br />
<br />
=== Proposed ===<br />
<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
* [https://github.com/mozilla/application-services Sync/FxA components]<br />
** '''Why Rust?''' Single safe and performant implementation which is shared across all our products.<br />
* libcubeb Audio backend for Windows (WASAPI)<br />
* Replace the XML parser, possibly via c2rust: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
* Rewrite the ICE stack used by WebRTC; {{bug|1616966}}<br />
** '''Why Rust?''' Works with network data.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
** [https://github.com/mozilla/dump_syms/ dump_syms], a reimplementation of Google Breakpad's dump_syms tool for Windows. Used to parse PDB files and print out Breakpad-compatible symbol files. <br />
*** '''Why Rust?''' Doesn't rely on Microsoft closed-source libraries anymore, can be cross-compiled and run on a non-Windows host, is an order of magnitude faster, takes less than a third of the memory, produces better symbols and relies on an active and friendly upstream [https://github.com/getsentry/symbolic/ symbolic]<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/components various sync-related components used on iOS and Fenix], includes a cross-compiled FxA Rust client, and storage/syncing of bookmarks, history, logins, tabs and webextensions data.<br />
* [https://github.com/mozilla/fix-stacks/ fix-stacks], a stack frame symbolizer: {{bug|1596292}}<br />
** '''Why Rust?''' High performance needed, a single implementation can replace multiple platform-specific scripts, and we can use the [https://github.com/getsentry/symbolic/ symbolic] crate to do all the hard parts.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* Berlin, January 2020 (minutes lost due to technical issues, unfortunately)<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Modules/Core&diff=1226433Modules/Core2020-04-23T11:02:14Z<p>Nnethercote: </p>
<hr />
<div><noinclude><br />
'''Only module owners may edit this page.''' <br />
<br />
They may:<br />
<br />
* update any information about their module except the name of the owner<br />
* add or remove sub-modules<br />
* change the owner of a sub-module <br />
* add emeritus owners or peers<br />
<br />
Other changes, including changes of module owner or addition/removal of modules, must be agreed with the Module Ownership Module group, probably via a discussion in [https://www.mozilla.org/about/forums/#governance mozilla.governance].<br />
</noinclude><br />
{{Module<br />
|name=Accessibility<br />
|description=Support for platform accessibility APIs. Accessibility APIs are used by 3rd party software like screen readers, screen magnifiers, and voice dictation software, which need information about document content and UI controls, as well as important events like changes of focus.<br />
|owner=[mailto:jteh@mozilla.com Jamie Teh]<br />
|peers=[mailto:eitan@monotonous.org Eitan Isaacson], [mailto:jteh@mozilla.com James Teh], [mailto:mzehe@mozilla.com Marco Zehe], [mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|ownersemeritus=[mailto:aaron@moonset.net. Aaron Leventhal], [mailto:surkov.alexander@gmail.com Alexander Surkov]<br />
|peersemeritus=[mailto:dbolter@mozilla.com David Bolter], [mailto:tbsaunde+mozbugs@tbsaunde.org Trevor Saunders], [mailto:ginn.chen@oracle.com Ginn Chen], Evan Yan<br />
|group=dev-accessibility<br />
|source_dirs=accessible/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=Animation<br />
|description=Declarative animations: CSS animations, CSS transitions, Web Animations API, and off-main thread animations.<br />
|owner=[mailto:bbirtles@mozilla.com Brian Birtles] (:birtles)<br />
|peers=[mailto:hiro@mozilla.com Hiroyuki Ikezoe] (:hiro), [mailto:mwoodrow@mozilla.com Matt Woodrow] (:mattwoodrow)<br />
|group=dev-tech-layout<br />
|source_dirs=dom/animation; and animation-related and interpolation-related code in layout/style, gfx/layers, servo/components/style and servo/ports/gecko<br />
|components=Core::DOM::Animation, Core::CSS Transitions and Animations<br />
}}<br />
<br />
{{Module<br />
|name=Anti-Tracking<br />
|description=Tracking detection and content-blocking.<br />
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]<br />
|peers=[mailto:dlee@mozilla.com Dimi Lee], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:ewright@mozilla.com Erica Wright], [mailto:jhofmann@mozilla.com Johann Hofmann]<br />
|group=dev-platform<br />
|source_dirs=toolkit/components/antitracking/, several files under browser/ and netwerk/url-classifier/<br />
|components=Core::Privacy: Anti-Tracking<br />
}}<br />
<br />
{{Module<br />
|name=Browser WebAPI<br />
|description=Web API for rendering apps, browser windows and widgets.<br />
|owner=[mailto:Olli.Pettay@helsinki.fi Olli Pettay]<br />
|peers=[mailto:fabrice@mozilla.com Fabrice Desré]<br />
|ownersemeritus=[mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|group=dev-webapi<br />
|source_dirs=dom/browser-element/<br />
|url=<br />
|components=Core::DOM<br />
}}<br />
<br />
{{Module<br />
|name=Build and Release Tools<br />
|description=Tools related to build and release automation and configuration of release builds.<br />
|owner=[mailto:nthomas@mozilla.com Nick Thomas]<br />
|peers=[mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:coop@mozilla.com Chris Cooper]<br />
|group=release-engineering<br />
|source_dirs=browser/config/mozconfigs/, mobile/android/config/mozconfigs/, xulrunner/config/mozconfigs/, b2g/config/, tools/update-packaging/<br />
|url=https://wiki.mozilla.org/ReleaseEngineering<br />
|components=Release Engineering::*<br />
}}<br />
<br />
{{Module<br />
|name=Build Config<br />
|description=The build system for Gecko and several mozilla.org hosted Gecko-based applications.<br />
|owner=[mailto:mh@glandium.org Mike Hommey] (:glandium)<br />
|peers=[mailto:mshal@mozilla.com Mike Shal] (:mshal), [mailto:nfroyd@mozilla.com Nathan Froyd] (:froydnj), [mailto:dmajor@mozilla.com David Major] (:dmajor), [mailto:rstewart@mozilla.com Ricky Stewart] (:ricky)<br />
|ownersemeritus=Chris Manchester (2019-2020), Gregory Szorc (2013-2019), Ted Mielczarek (2008-[https://blog.mozilla.org/ted/2013/03/07/gregory-szorc-is-now-the-build-config-module-owner/ 2013]), Benjamin Smedberg (???-[http://benjamin.smedbergs.us/blog/2008-04-30/more-changing-of-the-guard-ted-mielczarek/ 2008]), <br />
|peersemeritus=Ted Mielczarek, Ralph Giles, Gregory Szorc, Chris Manchester<br />
|group=dev-builds<br />
|source_dirs=build/, config/, python/mozbuild, tools/cross-commit, tools/cvs2hg-import.py, tools/cvsmgmt/, tools/elf-dynstr-gc/, tools/trees.pl, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/<br />
|url=http://www.mozilla.org/build/<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Code Analysis and Debugging Tools<br />
|description=Tools for debugging Mozilla code or for analyzing speed, memory use, and other characteristics of it.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=<br />
|group=dev-performance<br />
|source_dirs=tools/codesighs/, tools/debug/, tools/dreftool/, tools/dumpdeps/, tools/jprof/, tools/leak-gauge/, tools/leaky/, tools/memory/, tools/module-deps/, tools/performance/, tools/post_compile/, tools/preloader/, tools/rb/, tools/reorder/, tools/trace-malloc/, tools/uuiddeps/, <br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Content Security<br />
|description=Native content-based security features enforced in the ContentSecurityManager, including: Content Security Policy (CSP), Mixed Content Blocker (MCB), Referrer Policy, Subresource Integrity (SRI), Cross-Origin Resource Sharing (CORS) and top-level data: URI blocking.<br />
|owner=[mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]<br />
|peers=[mailto:tvyas@mozilla.com Tanvi Vyas], [mailto:dveditz@mozilla.com Dan Veditz], [mailto:amarchesini@mozilla.com Andrea Marchesini], [mailto:jkt@mozilla.com Jonathan Kingston], [mailto:tnguyen@mozilla.com Thomas Nguyen]<br />
|peersemeritus=[mailto:mozilla@sidstamm.com Sid Stamm], [mailto:jonas@sicking.cc Jonas Sicking], François Marier<br />
|group=dev-security<br />
|source_dirs=dom/security<br />
|components=Core::DOM: Security<br />
}}<br />
<br />
{{Module<br />
|name=Cookies<br />
|description=<br />
|owner=[mailto:amarchesini@mozilla.com Andrea Marchesini]<br />
|peers=[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:honzab.moz@firemni.cz Honza Bambas] <br />
|ownersemeritus=Monica Chew<br />
|peersemeritus=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]<br />
|group=dev-platform<br />
|source_dirs=netwerk/cookie/<br />
|url=<br />
|components=Core::Networking: Cookies<br />
}}<br />
<br />
{{Module<br />
|name=Permissions<br />
|description=<br />
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:amarchesini@mozilla.com Andrea Marchesini], [mailto:honzab.moz@firemni.cz Honza Bambas]<br />
|ownersemeritus=Monica Chew<br />
|peersemeritus=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]<br />
|group=dev-platform<br />
|source_dirs=extensions/permissions/<br />
|url=<br />
|components=Core :: Permission Manager<br />
}}<br />
<br />
{{Module<br />
|name=Cycle Collector<br />
|description=Code to break and collect objects within reference cycles<br />
|owner=[https://mozillians.org/en-US/u/mccr8/ Andrew McCreight]<br />
|peers=Peter Van der Beken, Olli Pettay, David Baron<br />
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers<br />
|components=Core::XPCOM<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=C++/Rust usage, tools, and style<br />
|description=Aspects of C++ use such as language feature usage, standard library versions/usage, compiler/toolchain versions, formatting and naming style, and aspects of Rust use as needs arise<br />
|owner=[mailto:eakhgari@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:bballo@mozilla.com Botond Ballo], [mailto:glandium@mozilla.com Mike Hommey], [mailto:jwalden@mozilla.com Jeff Walden], [mailto:sgiesecke@mozilla.com Simon Giesecke]<br />
|source_dirs=non-third-party C++ and Rust code in the tree<br />
|components=Various components<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=docshell<br />
|description=<br />
|owner=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:nika@thelayzells.com Nika Layzell]<br />
|peers=[mailto:peterv@propagandism.org Peter Van der Beken], [mailto:afarre@mozilla.com Andreas Farre]<br />
|ownersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:justin.lebar@gmail.com Justin Lebar], [mailto:sawang@mozilla.com Samael Wang], [mailto:kyle@nonpolynomial.com Kyle Machulis]<br />
|group=dev-platform<br />
|source_dirs=docshell/, uriloader/<br />
|url=<br />
|components=Core::Document Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Document Object Model<br />
|description=<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:hsivonen@iki.fi Henri Sivonen], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:baku@mozilla.com Andrea Marchesini],<br />
[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:nika@thelayzells.com Nika Layzell], [mailto:afarre@mozilla.com Andreas Farre], [mailto:emilio@crisal.io Emilio Cobos]<br />
|ownersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|peersemeritus=[mailto:justin.lebar@gmail.com Justin Lebar], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:bent.mozilla@gmail.com Ben Turner], [mailto:mounir@lamouri.fr Mounir Lamouri], [mailto:me@kylehuey.com Kyle Huey], [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:ben@wanderview.com Ben Kelly], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:kyle@nonpolynomial.com Kyle Machulis], [mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/*, except directories covered by other modules<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML<br />
}}<br />
<br />
{{Module<br />
|name=DOM File<br />
|description=DOM Blob, File and FileSystem APIs <br />
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]<br />
|peers=[mailto:olli@pettay.fi Olli Pettay]<br />
|group=dev-platform<br />
|source_dirs=dom/file, dom/filesystem<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: File<br />
}}<br />
<br />
{{Module<br />
|name=Event Handling<br />
|description=DOM Events and Event Handling <br />
|owner=[mailto:olli@pettay.fi Olli Pettay], [mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:echen@mozilla.com Edgar Chen]<br />
|peersemeritus=[mailto:sshih@mozilla.com Stone Shih]<br />
|group=dev-platform<br />
|source_dirs=dom/events and event handling related code elsewhere <br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: Events, Core::DOM: UI Events & Focus Handling<br />
}}<br />
<br />
{{Module<br />
|name=Web Workers<br />
|description=<br />
|owner=[mailto:baku@mozilla.com Andrea Marchesini]<br />
|peers=[mailto:mrbkap@mozilla.com Blake Kaplan], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey], [mailto:bkelly@mozilla.com Ben Kelly], [mailto:asuth@mozilla.com Andrew Sutherland], [mailto:ytausky@mozilla.com Yaron Tausky]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|group=dev-platform<br />
|source_dirs=dom/workers/<br />
|url=https://developer.mozilla.org/En/Using_web_workers<br />
|components=Core::DOM: Workers<br />
}}<br />
<br />
{{Module<br />
|name=IndexedDB<br />
|description=<br />
|owner=[mailto:jvarga@mozilla.com Jan Varga]<br />
|peers=[mailto:btseng@mozilla.com Bevis Tseng], [mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:baku@mozilla.com Andrea Marchesini]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey]<br />
|group=dev-platform<br />
|source_dirs=dom/indexedDB/<br />
|url=https://developer.mozilla.org/en/IndexedDB<br />
|components=Core::DOM: IndexedDB<br />
}}<br />
<br />
{{Module<br />
|name=Editor<br />
|description=<br />
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-platform<br />
|source_dirs=editor/<br />
|url=http://www.mozilla.org/editor/<br />
|components=Core::Editor<br />
}}<br />
<br />
{{Module<br />
|name=Gecko Profiler<br />
|description=Gecko's built-in profiler<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|peers=[mailto:nnethercote@mozilla.com Nicholas Nethercote], [mailto:gsquelart@mozilla.com Gerald Squelart], [mailto:gtatum@mozilla.com Greg Tatum], [mailto:canaltinova@mozilla.com Nazim Can Altinova], [mailto:jseward@mozilla.com Julian Seward] (LUL), [mailto:kvijayan@mozilla.com Kannan Vijayan] (JS integration), [mailto:brennie@mozilla.com Barret Rennie] (Screenshots).<br />
|ownersemeritus=[mailto:b56girard@gmail.com Benoit Girard]<br />
|peersemeritus=[mailto:shu@mozilla.com Shu-yu Guo] (JS integration), [mailto:tlee@mozilla.com Thinker Lee] (TaskTracer), [mailto:cyu@mozilla.com Cervantes Yu] (TaskTracer)<br />
|group=dev-platform<br />
|source_dirs=tools/profiler/<br />
|url=https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler<br />
|components=Core::Gecko Profiler<br />
}}<br />
<br />
{{Module<br />
|name=Global Key Bindings<br />
|description=Global hot keys in Mozilla for the browser, editor, mail-news and widgets. Does not include underlined menu accelerators and the like, as those are part of i18n.<br />
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|group=dev-accessibility<br />
|source_dirs=dom/events (and platform specific directories under it)<br />
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html<br />
|components=Core::Keyboard: Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Graphics<br />
|description=Mozilla graphics API<br />
|owner=[mailto:jrmuizel@mozilla.com Jeff Muizelaar](Thebes, QCMS, YCbCr, Cairo/Pixman, Regions, OS X, Other)<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:bas.schouten@live.nl Bas Schouten](Layers, Windows), [mailto:jgilbert@mozilla.com Jeff Gilbert](WebGL, ANGLE), [mailto:mwoodrow@mozilla.com Matt Woodrow](Layers API), [mailto:jfkthame@googlemail.com Jonathan Kew](text/fonts), [mailto:nsilva@mozilla.com Nicolas Silva](MozSurface), [mailto:ncameron@mozilla.com Nick Cameron], [mailto:sikeda@mozilla.com Sotaro Ikeda](B2G), [mailto:jnicol@mozilla.com Jamie Nicol](Android), [mailto:snorp@mozilla.com James Willcox](Android), [mailto:mstange@themasta.com Markus Stange](OS X), [mailto:lsalzman@mozilla.com Lee Salzman](Skia, Canvas2D), [mailto:rhunt@mozilla.com Ryan Hunt](OMTP), [mailto:gwatson@mozilla.com Glenn Watson ](WebRender), [mailto:dmalyshau@mozilla.com Dzmitry Malyshau](WebRender)<br />
|peersemeritus=[mailto:bgirard@mozilla.com Benoit Girard](Compositor, Performance), [mailto:ajuma.bugzilla@alijuma.com Ali Juma], [mailto:george@mozilla.com George Wright](Canvas2D), [mailto:mchang@mozilla.com Mason Chang], [mailto:dvander@mozilla.com David Anderson], [mailto:clord@mozilla.com Christopher Lord], [mailto:jdaggett@mozilla.com John Daggett](text/fonts), [mailto:bjacob@mozilla.com Benoit Jacob](gfx/gl), [mailto:jdrew@mozilla.com Joe Drew], [mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=gfx/, dom/canvas/<br />
|url=https://wiki.mozilla.org/Platform/GFX https://wiki.mozilla.org/Gecko:Layers https://wiki.mozilla.org/Gecko:2DGraphicsSketch<br />
|components=Core::Graphics, Core::Graphics: Layers, Core::Graphics: Text, Core::Graphics: WebRender, Core::GFX: Color Management, Core::Canvas: 2D, Core::Canvas: WebGL<br />
}}<br />
<br />
{{Module<br />
|name=WebGPU (Graphics submodule)<br />
|description=WebGPU implementation<br />
|owner=[mailto:dmalyshau@mozilla.com Dzmitry Malyshau]<br />
|peers=[mailto:josh@joshgroves.com Joshua Groves], [mailto:jgilbert@mozilla.com Jeff Gilbert],<br />
|group=dev-platform<br />
|source_dirs=dom/webgpu<br />
|url=https://wiki.mozilla.org/Platform/GFX/WebGPU<br />
|components=Core::Graphics::WebGPU<br />
}}<br />
<br />
{{Module<br />
|name=APZ (Graphics submodule)<br />
|description=Asynchronous panning and zooming<br />
|owner=[mailto:kgupta@mozilla.com Kartikaya Gupta]<br />
|peers=[mailto:bballo@mozilla.com Botond Ballo], [mailto:tnikkel@mozilla.com Timothy Nikkel], [mailto:rhunt@mozilla.com Ryan Hunt], [mailto:mstange@mozilla.com Markus Stange]<br />
|group=dev-platform<br />
|source_dirs=gfx/layers/apz<br />
|url=https://wiki.mozilla.org/Platform/GFX/APZ<br />
|components=Core::Panning and Zooming<br />
}}<br />
<br />
{{Module<br />
|name=Moz2D (Graphics submodule)<br />
|description=Platform independent 2D graphics API<br />
|owner=[mailto:bschouten@mozilla.com Bas Schouten]<br />
|peers=[mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:gwright@mozilla.com George Wright], [mailto:jwatt@jwatt.org Jonathan Watt]<br />
|group=dev-platform<br />
|source=gfx/2d<br />
|url=https://wiki.mozilla.org/Platform/GFX/Moz2D<br />
|components=Core::Graphics<br />
}}<br />
<br />
{{Module<br />
|name=Legacy HTML Parser<br />
|description=<br />
|owner=[mailto:mrbkap@gmail.com Blake Kaplan]<br />
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:rbs@maths.uq.edu.au rbs@maths.uq.edu.au]<br />
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|source_dirs=parser/htmlparser<br />
|url=http://www.mozilla.org/newlayout/doc/parser.html<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=HAL<br />
|description=Hardware Abstraction Layer<br />
|owner=[mailto:gsvelto@mozilla.com Gabriele Svelto]<br />
|peers=<br />
|group=dev-platform<br />
|source_dirs=hal/<br />
|components=Core::Hardware Abstraction Layer (HAL)<br />
}}<br />
<br />
{{Module<br />
|name=HTML Parser<br />
|description=The HTML Parser transforms HTML source code into a DOM. It conforms to the HTML specification, and is mostly translated automatically from Java to C++.<br />
|owner=[mailto:hsivonen@iki.fi Henri Sivonen]<br />
|peers=[mailto:wchen@mozilla.com William Chen]<br />
|group=dev-platform<br />
|source_dirs=parser/html<br />
|url=http://about.validator.nu/<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=I18N Library<br />
|description=<br />
|owner=[mailto:hsivonen@hsivonen.fi Henri Sivonen (encoding)], [mailto:jfkthame@gmail.com Jonathan Kew (except to encoding)]<br />
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura], [mailto:gandalf@aviary.pl Zibi Braniecki], [mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]<br />
|ownersemeritus=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]<br />
|group=dev-i18n<br />
|source_dirs=intl/<br />
|url=http://mozilla.org/projects/intl/index.html<br />
|components=Core::Internationalization<br />
}}<br />
<br />
{{Module<br />
|name=ImageLib<br />
|description=<br />
|owner=[mailto:tnikkel@gmail.com Timothy Nikkel]<br />
|peers=[mailto:aosmond@mozilla.com Andrew Osmond], [mailto:jmuizelaar@mozilla.com Jeff Muizelaar]<br />
|peersemeritus=[mailto:seth.bugzilla@blackhail.net Seth Fowler], [mailto:netzen@gmail.com Brian Bondy], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-platform<br />
|source_dirs=media/libjpeg/, media/libpng/, image/, modules/zlib/<br />
|url=<br />
|components=Core::ImageLib<br />
}}<br />
<br />
{{Module<br />
|name=IPC<br />
|description=Native message-passing between threads and processes<br />
|owner=[mailto:jld@mozilla.com Jed Davis]<br />
|ownersemeritus=Chris Jones, Bill McCloskey<br />
|peers=[mailto:nika@thelayzells.com Nika Layzell], [mailto:jmathies@mozilla.com Jim Mathies], [mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:amccreight@mozilla.com Andrew McCreight]<br />
|peersemeritus=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bent.mozilla@gmail.com Ben Turner], David Anderson, Kan-Ru Chen, Bevis Tseng, Ben Kelly<br />
|group=dev-platform<br />
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/<br />
|url=<br />
|components=Core::IPC}}<br />
<br />
{{Module<br />
|name=JavaScript<br />
|description=JavaScript engine (SpiderMonkey)<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:jdemooij@mozilla.com Jan de Mooij], André Bargull, [mailto:tcampbell@mozilla.com Ted Campbell], [mailto:jcoppeard@mozilla.com Jon Coppeard], [mailto:sphink@gmail.com Steve Fink], [mailto:arai.unmht@gmail.com Tooru Fujisawa], [mailto:khyperia@mozilla.com Ashley Hauck], [mailto:evilpies@gmail.com Tom Schuster], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:jwalden@mit.edu Jeff Walden], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:till@tillschneidereit.net Till Schneidereit], [mailto:efaust@mozilla.com Eric Faust], [mailto:nfitzgerald@mozilla.com Nick Fitzgerald], [mailto:nnethercote@mozilla.com Nick Nethercote], [mailto:luke@mozilla.com Luke Wagner], [mailto:sunfish@mozilla.com Dan Gohman], [mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peersemeritus=[mailto:brendan@mozilla.org Brendan Eich], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:nmatsakis@mozilla.com Niko Matsakis], [mailto:ejpbruel@mozilla.com Eddy Bruel], [mailto:danderson@mozilla.com David Anderson], [mailto:igor@mir2.org Igor Bukanov], Andreas Gal<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src<br />
|url=http://www.mozilla.org/js/spidermonkey,<br />
http://developer.mozilla.org/en/docs/About_JavaScript<br />
|components=Core::JavaScript Engine<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript JIT<br />
|description=JavaScript engine's JIT compilers (IonMonkey, Baseline)<br />
|owner=[mailto:jdemooij@mozilla.com Jan de Mooij]<br />
|peers=[mailto:bbouvier@mozilla.com Benjamin Bouvier], [mailto:tcampbell@mozilla.com Ted Campbell], [mailto:mgaudet@mozilla.com Matthew Gaudet], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:iireland@mozilla.com Iain Ireland], [mailto:nicolas.b.pierron@mozilla.com Nicolas Pierron], [mailto:evilpies@gmail.com Tom Schuster], [mailto:sstangl@mozilla.com Sean Stangl], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:luke@mozilla.com Luke Wagner]<br />
|peersemeritus=[mailto:danderson@mozilla.com David Anderson], [mailto:hv1989@gmail.com Hannes Verschore]<br />
|group=dev-tech-js-engine-internals<br />
|source_dirs=js/src/jit<br />
|url=http://www.mozilla.org/js/spidermonkey<br />
|components=Core::JavaScript Engine: JIT<br />
}}<br />
<br />
{{Module<br />
|name=jsat<br />
|description=Javascript screen reader that is used in Android and B2G<br />
|owner=[mailto:eitan@monotonous.org Eitan Isaacson]<br />
|peers=[mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|group=dev-accessibility<br />
|source_dirs=accessible/jsat/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=js-ctypes<br />
|description=A foreign function interface which allows privileged JS code to interact with binary code without using XPCOM/XPConnect.<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src/ctypes/<br />
|url=https://wiki.mozilla.org/JSctypes<br />
|components=Core::js-ctypes<br />
}}<br />
<br />
{{Module<br />
|name=js-tests<br />
|description=JavaScript test suite<br />
|owner=[mailto:bclary@bclary.com Bob Clary]<br />
|peers=<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tests/<br />
|url=http://www.mozilla.org/js/tests/library.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Layout Engine<br />
|description=rendering tree construction, layout (reflow), etc.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:jfkthame@gmail.com Jonathan Kew], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:matt.woodrow@gmail.com Matt Woodrow], [mailto:xidorn+moz@upsuper.org Xidorn Quan], [mailto:emilio@crisal.io Emilio Cobos Álvarez]<br />
|peersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/printing/, layout/tables/, layout/tools/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Layout<br />
|components=Core::Layout, Core::Layout: Block and Inline, Core::Layout: Columns, Core::Layout: Flexbox, Core::Layout: Floats, Core::Layout: Form Controls, Core::Layout: Generated Content, Lists, and Counters, Core::Layout: Grid, Core::Layout: Images, Video, and HTML Frames, Core::Layout: Positioned, Core::Layout: Ruby, Core::Layout: Scrolling and Overflow, Core::Layout: Tables, Core::Layout: Text and Fonts, Core::Print Preview, Core::Printing: Output<br />
}}<br />
<br />
{{Module<br />
|name=libjar<br />
|description=The JAR handling code (protocol handler, stream implementation, and zipreader/zipwriter).<br />
|owner=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|ownersemeritus=Taras Glek, Michael Wu<br />
|peers=[mailto:mnovotny@mozilla.com Michal Novotny], [mailto:vgosu@mozilla.com Valentin Gosu]<br />
|group=dev-platform<br />
|source_dirs=modules/libjar<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MathML<br />
|description=MathML is a low-level specification for describing mathematics which provides a foundation for the inclusion of mathematical expressions in Web pages.<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-tech-mathml<br />
|source_dirs=layout/mathml/<br />
|url=http://www.mozilla.org/projects/mathml/<br />
|components=Core::MathML<br />
}}<br />
<br />
{{Module<br />
|name=Media Playback<br />
|description=HTML Media APIs, including Media Source Extensions and non-MSE video/audio element playback, and Encrypted Media Extensions. (WebRTC and WebAudio not included).<br />
|owner=[mailto:jyavenard@mozilla.com Jean-Yves Avenard]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:cpearce@mozilla.com Chris Pearce]<br />
|peers=[mailto:kinetik@flim.org Matthew Gregan], [mailto:bvandyk@mozilla.com Bryce Van Dyk], [mailto:jolin@mozilla.com John Lin], [mailto:alwu@mozilla.com Alastor Wu], [mailto:jwwang@mozilla.com JW Wang]<br />
|group=dev-media<br />
|source_dirs=dom/media, media/gmp-clearkey/, media/libcubeb/, media/libnestegg/, media/libogg/, media/libopus/, media/libstagefright/, media/libtheora/, media/libtremor/, media/libvorbis/, media/libvpx/, media/omx-plugin/, media/rlz/<br />
|url=<br />
|components=Core::Audio/Video<br />
}}<br />
<br />
{{Module<br />
|name=Media Transport<br />
|description=Pluggable transport for real-time media<br />
|owner=[mailto:ekr@rtfm.com Eric Rescorla]<br />
|peers=[mailto:bcampen@mozilla.com Byron Campen], [mailto:abr@mozilla.com Adam Roach], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]<br />
|group=dev-media<br />
|source_dirs=media/mtransport<br />
|url=<br />
|components=Core::WebRTC::Networking<br />
}}<br />
<br />
{{Module<br />
|name=Memory Allocator<br />
|description=Most things related to memory allocation in Gecko, including jemalloc, replace-malloc, DMD (dark matter detector), logalloc, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:n.nethercote@gmail.com Nicholas Nethercote], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-platform<br />
|source_dirs=memory/<br />
|components=Core::DMD, Core::jemalloc<br />
}}<br />
<br />
{{Module<br />
|name=mfbt<br />
|description=mfbt is a collection of headers, macros, data structures, methods, and other functionality available for use and reuse throughout all Mozilla code (including SpiderMonkey and Gecko more broadly).<br />
|owner=[mailto:jwalden@mit.edu Jeff Walden]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:Ms2ger@gmail.com Ms2ger], [mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|group=dev-platform<br />
|source_dirs=mfbt/<br />
|url=<br />
|components=Core::MFBT<br />
}}<br />
<br />
{{Module<br />
|name=Mozglue<br />
|description=Glue library containing various low-level functionality, including a dynamic linker for Android, a DLL block list for Windows, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd] (mozglue/linker), [mailto:kgupta@mozilla.com Kartikaya Gupta] (mozglue/android), [mailto:nchen@mozilla.com Jim Chen] (mozglue/android), [mailto:aklotz@mozilla.com Aaron Klotz] (Windows Dll Blocklist/Interceptor)<br />
|group=dev-platform<br />
|source_dirs=mozglue/<br />
|components=Core::mozglue<br />
}}<br />
<br />
{{Module<br />
|name=mozilla-toplevel<br />
|description=The top level directory for the mozilla tree.<br />
|owner=[[Modules/Firefox_Technical_Leadership|Firefox Technical Leadership module]]<br />
|ownersemeritus=[mailto:brendan@mozilla.org Brendan Eich]<br />
|peers=<br />
|group=<br />
|source_dirs=tools/README<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MSCOM<br />
|description=Integration with Microsoft Distributed COM<br />
|owner=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|peers=[mailto:jteh@mozilla.com James Teh], [mailto:jmathies@mozilla.com Jim Mathies]<br />
|group=dev-platform<br />
|source_dirs=ipc/mscom/%<br />
|url=<br />
|components=Core::IPC: MSCOM}}<br />
<br />
{{Module<br />
|name=Necko<br />
|description=The Mozilla Networking Library<br />
|owner=[mailto:dd.mozilla@gmail.com Dragana Damjanovic]<br />
|peers= [mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:mnovotny@mozilla.com Michal Novotny], [mailto:valentin.gosu@gmail.com Valentin Gosu], [mailto:kershaw@mozilla.com Kershaw Chang]<br />
|ownersemeritus=[mailto:mcmanus@ducksong.com Patrick McManus], [mailto:cbiesinger@gmail.com Christian Biesinger] |peersemeritus= Shih-Chiang Chien, [mailto:bzbarsky@mit.edu Boris Zbarsky], Steve Workman, Nick Hurley, [mailto:daniel@haxx.se Daniel Stenberg ], [mailto:jduell.mcbugs@gmail.com Jason Duell]<br />
|group=dev-tech-network<br />
|source_dirs=netwerk/%, netwerk/base/, netwerk/build/, netwerk/cache/, netwerk/dns/, netwerk/locales/, netwerk/mime/, netwerk/protocol/, netwerk/resources/, netwerk/socket/, netwerk/streamconv/, netwerk/system/, netwerk/test/, netwerk/testserver/<br />
|url=http://www.mozilla.org/projects/netlib/, https://developer.mozilla.org/en/Necko<br />
|components=Core::Networking, Core::Networking: Cache, Core::Networking: Cookies, Core::Networking: FTP, Core::Networking: File, Core::Networking: HTTP, Core::Networking: JAR, Core::Networking: Websockets<br />
}}<br />
<br />
{{Module<br />
|name=NodeJS usage, tools, and style<br />
|description=Advises on the use of NodeJS and npm packages at build and runtime. Reviews additions/upgrades/removals of vendored npm packages. Works with appropriate teams to maintain automated license and security audits of npm packages. Works with the security team and relevant developers to respond to vulnerabilities in NodeJS and vendored npm packages.<br />
|owner=[mailto:dmosedale@mozilla.com Dan Mosedale]<br />
|peers=[mailto:mbanner@mozilla.com Mark Banner], [mailto:dcoates@mozilla.com Danny Coates], [mailto:khudson@mozilla.com Kate Hudson], [mailto:jlaster@mozilla.com Jason Laster], [mailto:elee@mozilla.com Ed Lee], [mailto:dtownsend@mozilla.com Dave Townsend]<br />
|source_dirs=package.json, package-lock.json, node_modules and others as appropriate<br />
|components=Various components<br />
|forum=[https://wiki.mozilla.org/Firefox/firefox-dev firefox-dev], #nodejs on slack<br />
}}<br />
<br />
{{Module<br />
|name=NSPR<br />
|description=Netscape Portable Runtime<br />
|owner=[mailto:kaie@kuix.de Kai Engert]<br />
|peers=[mailto:mh@glandium.org Mike Hommey]<br />
|ownersemeritus=[mailto:wtc@google.com Wan-Teh Chang]<br />
|group=dev-tech-nspr<br />
|source_dirs=nsprpub/<br />
|url=http://www.mozilla.org/projects/nspr/<br />
http://www.mozilla.org/projects/nspr/reference/html/<br />
http://www.mozilla.org/projects/nspr/release-notes/<br />
|components=NSPR<br />
}}<br />
<br />
{{Module<br />
|name=PDF<br />
|description=Rendering code to display documents encoded in the ISO 32000-1 `PDF' format.<br />
|owner=[mailto:bdahl@mozilla.com Brendan Dahl]<br />
|peers=[mailto:aadib@mozilla.com Artur Adib], [mailto:vnicolas@mozilla.com Vivien Nicolas]<br />
|group=dev-platform<br />
|source_dirs=media/pdf/<br />
|url=https://github.com/mozilla/pdf.js<br />
|components=Core::PDF<br />
}}<br />
<br />
{{Module<br />
|name=Plugins<br />
|description= NPAPI Plugin support.<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:davidp99@gmail.com David Parks]<br />
|peersemeritus=[mailto:joshmoz@gmail.com Josh Aas], [mailto:john@pointysoftware.net John Schoenick], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:jstenback@gmail.com Johnny Stenback], Benjamin Smedberg<br />
|group=<br />
|source_dirs=dom/plugins/, modules/plugin/<br />
|url=https://wiki.mozilla.org/Plugins<br />
|components=Core::Plug-ins<br />
}}<br />
<br />
{{Module<br />
|name=Preferences<br />
|description=Preference library<br />
|owner=[mailto:nnethercote@mozilla.com Nicholas Nethercote]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:glandium@mozilla.com Mike Hommey], [mailto:erahm@mozilla.com Eric Rahm], [mailto:kwright@mozilla.com Kristen Wright]<br />
|peersemeritus=Felipe Gomes<br />
|group=dev-platform<br />
|source_dirs=modules/libpref/<br />
|url=<br />
|components=Core::Preferences: Backend<br />
}}<br />
<br />
{{Module<br />
|name=Private Browsing<br />
|description=Implementation of the Private Browsing mode, and the integration of other modules with Private Browsing APIs.<br />
|owner=[mailto:eakhgari@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:josh@joshmatthews.net Josh Matthews]<br />
|group=dev-platform<br />
|source_dirs=Implementation and consumers of Private Browsing APIs in nsILoadContext, nsIPrivateBrowsingChannel, PrivateBrowsingUtils.jsm and the related glue code. <br />
|url=https://wiki.mozilla.org/Private_Browsing<br />
|components=Firefox::Private Browsing<br />
}}<br />
<br />
{{Module<br />
|name=Privilege Manager<br />
|description="caps"<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]<br />
|peersemeritus=[mailto:brendan@mozilla.org Brendan Eich], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:dveditz@mozilla.com Dan Veditz]<br />
|group=dev-tech-dom<br />
|source_dirs=caps/<br />
|url=http://www.mozilla.org/projects/security/components/index.html<br />
|components=Core::Security: CAPS<br />
}}<br />
<br />
{{Module<br />
|name=Push Notifications<br />
|description=Push is a way for application developers to send messages to their web applications.<br />
|owners=[mailto:lina@mozilla.com Lina Cambridge]<br />
|ownersemeritus=[mailto:doug.turner@gmail.com Doug Turner]<br />
|peers=[mailto:mt@lowentropy.net Martin Thomson], [mailto:ddamjanovic@mozilla.com Dragana Damjanovic]<br />
|peersemeritus=[mailto:nsm.nikhil@gmail.com Nikhil Marathe]<br />
|group=<br />
|source_dirs=dom/push<br />
|url=<br />
|components=Core::DOM: Push Notifications<br />
}}<br />
<br />
{{Module<br />
|name=security<br />
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)<br />
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:mt@lowentropy.net Martin Thomson]<br />
|ownersemeritus=[mailto:wtc@google.com Wan-Teh Chang], [mailto:ttaubert@mozilla.com Tim Taubert]<br />
|peers=[mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi], [mailto:ekr@rtfm.com Eric Rescorla], [mailto:franziskuskiefer@gmail.com Franziskus Kiefer], [mailto:dueno@redhat.com Daiki Ueno]<br />
|peersemeritus=[mailto:emaldona@redhat.com Elio Maldonado]<br />
|group=dev-tech-crypto<br />
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/<br />
|url=http://mozilla.org/projects/security/pki/<br />
|components=NSS, JSS, Core::Security, Core::Security: S/MIME<br />
}}<br />
<br />
{{Module<br />
|name=Security - Mozilla PSM Glue<br />
|description=Personal Security Manager<br />
|owner=[mailto:dkeeler@mozilla.com Dana Keeler]<br />
|ownersemeritus=[mailto:kaie@kuix.de Kai Engert (2001-2012)]<br />
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:cykesiopka.bmo@gmail.com Cykesiopka], [mailto:jc@mozilla.com J.C. Jones], [mailto:fkiefer@mozilla.com Franziskus Kiefer]<br />
|group=dev-tech-crypto<br />
|source_dirs=security/manager/<br />
|url=<br />
|components=Core::Security: PSM<br />
}}<br />
<br />
{{Module<br />
|name=Static analysis & rewriting for C++<br />
|description=Tools for checking C++ code looking for problems at compile time, plus tools for automated rewriting of C++ code.<br />
|owner=[mailto:andi@mozilla.com Andi-Bogdan Postelnicu]<br />
|peers=[mailto:nika@thelayzells.com Nika Layzell], [mailto:sfink@mozilla.com Steve Fink], [mailto:jrmuizel@mozilla.com Jeff Muizelaar], [mailto:eakhgari@mozilla.com Ehsan Akhgari]<br />
|peersemeritus=[mailto:birunthan@mohanathas.com Birunthan Mohanathas]<br />
|group=dev-platform<br />
|source_dirs=build/clang-plugin, tools/rewriting among other out of tree tools<br />
|url=<br />
|components=Core::Rewriting & Analysis<br />
}}<br />
{{Module<br />
|name=storage<br />
|description=Storage APIs with a SQLite backend<br />
|owner=[mailto:mak77@bonardo.net Marco Bonardo]<br />
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:jvarga@mozilla.com Jan Varga]<br />
|group=dev-platform<br />
|source_dirs=db/sqlite3/, storage/<br />
|url=http://developer.mozilla.org/en/docs/Storage<br />
|components=Toolkit::Storage, Core::SQL<br />
}}<br />
<br />
{{Module<br />
|name=String<br />
|description=<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-tech-xpcom<br />
|source_dirs=string/, xpcom/string/<br />
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide<br />
|components=Core::String<br />
}}<br />
<br />
{{Module<br />
|name=Style System<br />
|description=CSS style sheet handling; style data computation<br />
|owner=[mailto:cam@mcc.id.au Cameron McCormack]<br />
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:emilio@crisal.io Emilio Cobos Álvarez], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:xidorn+moz@upsuper.org Xidorn Quan], [mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/style/, servo/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System<br />
|components=Core::CSS Parsing and Computation<br />
}}<br />
<br />
{{Module<br />
|name=SVG<br />
|description=Scalable Vector Graphics<br />
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]<br />
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]<br />
|group=dev-tech-svg<br />
|source_dirs=dom/svg/, layout/svg/, dom/smil/<br />
|url=https://developer.mozilla.org/en-US/docs/Web/SVG<br />
|components=Core::SVG<br />
}}<br />
<br />
{{Module<br />
|name=View System<br />
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]<br />
|group=dev-tech-layout<br />
|source_dirs=view/<br />
|url=<br />
|components=Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=Web Audio<br />
|description=Support for the W3C Web Audio API specification.<br />
|owner=[mailto:padenot@mozilla.com Paul Adenot]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:karlt+@karlt.net Karl Tomlinson]<br />
|group=dev-platform<br />
|source_dirs=dom/media/webaudio<br />
|url=https://wiki.mozilla.org/Web_Audio_API<br />
|components=Core::Web Audio<br />
}}<br />
<br />
{{Module<br />
|name=Web Painting<br />
|description=painting, display lists, and layer construction<br />
|owner=[mailto:matt.woodrow@gmail.com Matt Woodrow]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dbaron@dbaron.org David Baron], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:mstange@themasta.com Markus Stange], [mailto:mmynttinen@mozilla.com Miko Mynttinen], [mailto:jnicol@mozilla.com Jamie Nicol]<br />
|group=dev-tech-layout<br />
|source_dirs= layout/painting, the display list and layer related methods on nsIFrame and its subclasses<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|components=Core::Layout: Web Painting<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC<br />
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=netwerk/sctp (also see submodules "WebRTC Media" and "WebRTC Signaling")<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC, Core::WebRTC Networking<br />
}}<br />
<br />
{{Module<br />
|name=WebVR<br />
|description=Gecko's implementation of WebVR (Virtual Reality) functionality, including API, devices, graphics and integration<br />
|owner=[mailto:kgilbert@mozilla.com Kearwood (Kip) Gilbert]<br />
|peers=[mailto:dmu@mozilla.com Daosheng Mu], [mailto:igorostizaga@mozilla.com Imanol Fernández]<br />
|peersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=dom/vr, gfx/vr<br />
|url=https://mozvr.com/<br />
|components=Core::WebVR<br />
}}<br />
<br />
{{Module<br />
|name=Widget<br />
|description=Top level Widget<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|ownersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peersemeritus=[mailto:pavlov@pavlov.net Stuart Parmenter], <br />
|group=dev-platform<br />
|source_dirs=widget/, widget/xpwidgets/<br />
|url=<br />
|components=Core::Drag and Drop, Core::Widget, Core::Printing: Setup<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Android<br />
|description=Android widget support<br />
|owner=[mailto:jwillcox@mozilla.com James Willcox]<br />
|peers=<br />
|ownersemeritus=[mailto:blassey.bugs@lassey.us Brad Lassey]<br />
|group=dev-platforms-mobile<br />
|source_dirs=widget/android/, embedding/android<br />
|url=<br />
|components=Core::Widget: Android<br />
}}<br />
<br />
{{Module<br />
|name=Widget - GTK<br />
|description=GTK widget support<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:stransky@redhat.com Martin Stránský]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-platform<br />
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/<br />
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/<br />
|components=Core::Widget: Gtk<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Headless<br />
|description=Headless widget support<br />
|owner=[mailto:bdahl@mozilla.com Brendan Dahl]<br />
|peers=<br />
|ownersemeritus=<br />
|group=dev-platform<br />
|source_dirs=widget/headless/<br />
|url=<br />
|components=Firefox::Headless<br />
}}<br />
<br />
{{Module<br />
|name=Widget - OS X<br />
|description= OSX widget support<br />
|owner=[mailto:spohl@mozilla.com Stephen Pohl]<br />
|peers=[mailto:mstange@themasta.com Markus Stange]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:mstange@themasta.com Markus Stange]<br />
|peersemeritus=[mailto:joshmoz@gmail.com Josh Aas], [mailto:b56girard@gmail.com Benoit Girard], [mailto:smichaud@pobox.com Steven Michaud]<br />
|group=dev-platform<br />
|source_dirs=widget/cocoa/<br />
|url=<br />
|components=Core::Widget: Cocoa<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Windows<br />
|description=Windows widget support<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:robert.strong.bugs@gmail.com Rob Strong], [mailto:aklotz@mozilla.com Aaron Klotz]<br />
|peersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:doug.turner@gmail.com Doug Turner], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:robarnold@cmu.edu Rob Arnold]<br />
|group=dev-platform<br />
|source_dirs=widget/windows/<br />
|url=<br />
|components=Core::Widget: Win32<br />
}}<br />
<br />
{{Module<br />
|name=XML<br />
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-xml<br />
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/<br />
|url=http://www.mozilla.org/newlayout/xml/<br />
|components=Core::XML<br />
}}<br />
<br />
{{Module<br />
|name=XPApps<br />
|description=Cross-Platform Applications, mostly Navigator front end and application shell.<br />
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-apps-seamonkey<br />
|source_dirs=xpfe/<br />
|url=http://www.mozilla.org/xpapps/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPCOM<br />
|description=The cross-platform object model and core data structures.<br />
|owner=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]<br />
|peers=[mailto:erahm@mozilla.com Eric Rahm], [mailto:nika@thelayzells.com Nika Layzell], [mailto:kmaglione@mozilla.com Kris Maglione]<br />
|ownersemeritus=Benjamin Smedberg<br />
|peersemeritus=[https://mozillians.org/en-US/u/dougt/ Doug Turner]<br />
|group=dev-platform<br />
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/<br />
|url=http://developer.mozilla.org/en/XPCOM<br />
|components=Core::XPCOM<br />
}}<br />
<br />
{{Module<br />
|name=XPConnect<br />
|description=Deep Magic<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:kmaglione@mozilla.com Kris Maglione], [mailto:nika@thelayzells.com Nika Layzell]<br />
|peersemeritus=[mailto:gal@uci.edu Andreas Gal], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]<br />
|group=<br />
|source_dirs=js/xpconnect/<br />
|url=<br />
|components=Core::XPConnect<br />
}}<br />
<br />
{{Module<br />
|name=XPIDL<br />
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.<br />
|owner=[mailto:nika@thelayzells.com Nika Layzell]<br />
|peers=[mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:amccreight@mozilla.com Andrew McCreight]<br />
|ownersemeritus=[mailto:me@kylehuey.com Kyle Huey]<br />
|peersemeritus=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-tech-xpcom<br />
|source_dirs=xpcom/typelib/<br />
|url=http://www.mozilla.org/scriptable/xpidl<br />
http://www.mozilla.org/scriptable<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XSLT Processor<br />
|description=XSLT transformations processor<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xslt<br />
|source_dirs=dom/xslt/<br />
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html<br />
|components=Core::XSLT<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Windows <br />
|description=Sandboxing for the Windows platform <br />
|owner=[mailto:bobowencode@gmail.com Bob Owen] (:bobowen)<br />
|peers=[mailto:aklotz@mozilla.com Aaron Klotz] (:aklotz), [mailto:jimm@mozilla.com Jim Mathies] (:jimm), [mailto:davidp99@gmail.com David Parks] (:handyman)<br />
|ownersemeritus=[https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes]<br />
|peersemeritus=[mailto:netzen@gmail.com Brian Bondy]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/win <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - OSX <br />
|description=Sandboxing for the OSX platform <br />
|owner=[mailto:haftandilian@mozilla.com Haik Aftandilian]<br />
|peers=<br />
|group=dev-platform <br />
|source_dirs=security/sandbox/mac <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Linux<br />
|description=Sandboxing for the Linux platform<br />
|owner=[mailto:jld@mozilla.com Jed Davis]<br />
|peers=[mailto:gcp@mozilla.com Gian-Carlo Pascutto]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/linux<br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Crash reporting<br />
|description=Infrastructure and tools used to generate, submit and process crash reports. This includes the in-tree google-breakpad fork, the crash report generation machinery as well as the host tools used to dump symbols, analyse minidumps and generate stack traces.<br />
|owner=[mailto:gsvelto@mozilla.com Gabriele Svelto] (:gsvelto)<br />
|peers=[mailto:nfroyd@mozilla.com Nathan Froyd] (:froydnj)<br />
|group=dev-platform<br />
|source_dirs=toolkit/crashreporter, toolkit/components/crashes, tools/crashreporter, ipc/glue/CrashReporter*, mobile/android/geckoview/src/main/java/org/mozilla/geckoview/CrashReporter.java<br />
|url=https://firefox-source-docs.mozilla.org/toolkit/crashreporter/crashreporter/index.html<br />
|components=Toolkit::Crash Reporting<br />
}}<br />
<br />
===Submodules===<br />
{{Module<br />
|name=Build Config - Fennec<br />
|description=Submodule of the build config covering Fennec's build system in mobile/android.<br />
|owner=[mailto:nalexander@mozilla.com Nicholas Alexander]<br />
|peers=Same as Build Config<br />
|group=dev-builds<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Build Config - Taskgraph<br />
|description=Support for task-graph generation in decision, action, and cron tasks, including configuration of all tasks including those for CI, nightlies, and releases; as well as Docker and VM images used to execute those tasks.<br />
|owner=[mailto:mozilla@hocat.ca Tom Prince]<br />
|peers=[mailto:ahal@mozilla.com Andrew Halberstadt], [mailto:aki@mozilla.com Aki Sasaki], [mailto:bstack@mozilla.com Brian Stack], [mailto:mh@glandium.org Mike Hommey], [mailto:gps@mozilla.com Gregory Szorc], [mailto:jmaher@mozilla.com Joel Maher], [mailto:callek@mozilla.com Justin Wood], [mailto:dustin@mozilla.com Dustin Mitchell]<br />
|components=Firefox Build System::Task Configuration<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Media<br />
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:jib@mozilla.com Jan-Ivar Bruaroey], [mailto:dminor@mozilla.com Dan Minor], [mailto:apehrson@mozilla.com Andreas Pehrson], <br />
|peersemeritus=[mailto:pkerr@mozilla.com Paul Kerr], [mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc, /dom/media/webrtc, /dom/media/systemservices<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Audio/Video)<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Signaling<br />
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling<br />
|owner=[mailto:bcampen@mozilla.com Byron Campen]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:abr@mozilla.com Adam Roach], [mailto:rjesup@mozilla.com Randell Jesup], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc/signaling/<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Signaling)<br />
}}<br />
<br />
<noinclude><br />
<br />
===Unassigned Bugzilla Components===<br />
<br />
The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):<br />
<br />
<pre><br />
Core::Find Backend<br />
Core::General<br />
Core::History: Global<br />
Core::Image Blocking<br />
Core::Localization<br />
Core::Networking: Domain Lists<br />
Core::Selection<br />
Core::Serializers<br />
Core::Spelling checker<br />
Core::X-remote<br />
Core::XUL<br />
</pre><br />
</noinclude></div>Nnethercotehttps://wiki.mozilla.org/index.php?title=AWSY/Tests&diff=1225607AWSY/Tests2020-03-31T03:26:46Z<p>Nnethercote: </p>
<hr />
<div>== General ==<br />
Are We Slim Yet project (commonly known as AWSY) tracks memory usage across builds.<br />
<br />
On treeherder, the AWSY builds are listed in subgroups of `SY`.<br />
<br />
== Test Descriptions ==<br />
<br />
=== Base Content JS ===<br />
<br />
* An updated test focused on supporting fission. This measures the base overhead of an empty content process. It tracks resident unique, heap unclassified, JS, and explicit memory metrics as well as storing full memory reports as artifacts. The median value for each metric is used from across all content processes. It has much lower thresholds for alerting and is recorded in [https://wiki.mozilla.org/EngineeringProductivity/Projects/Perfherder Perfherder].<br />
<br />
==== Possible regression causes ====<br />
A change has caused more JavaScript to load at startup or into blank pages<br />
* '''Common solution:''' lazily load any new modules you rely on<br />
* '''Common solution:''' Split your code out to only load what is minimally needed initially<br />
You modified the JS engine and it's using more memory<br />
* '''Common solution:''' Attempt to reduce your object size for the common case, these tend to add up!<br />
You implemented a new feature in JavaScript<br />
* '''Common solution:''' Write the majority (or all of it) in compiled code (C++/Rust). This will reduce overhead and generally improve performance.<br />
<br />
=== Explicit Memory summary ===<br />
<br />
* This is memory explicitly reported by a memory reporter. It includes all the memory allocated via explicit calls to heap allocation functions (such as malloc and new), and some (only that covered by memory reporters) of the memory allocated via explicit calls to non-heap allocations functions (such as mmap and VirtualAlloc).<br />
<br />
==== Possible regression causes ====<br />
* A regression in this usually means a new feature is using or retaining more memory and should be looked at. These are easier to diagnose as we can compare memory reports.<br />
<br />
See the about:memory [https://developer.mozilla.org/docs/Mozilla/Performance/about:memory#Explicit_Allocations mdn page] for more details.<br />
<br />
=== Heap Unclassified summary ===<br />
<br />
* The "heap-unclassified" value represents heap-allocated memory that is not measured by any memory reporter. This is typically 10--20% of "explicit".<br />
<br />
==== Possible regression causes ====<br />
* A regression in this can indicate that we're leaking memory or that additional memory reporters should be added.<br />
* An improvement can indicate that leaks have been fixed or that we added new memory reporters.<br />
<br />
See the about:memory [https://developer.mozilla.org/docs/Mozilla/Performance/about:memory#Explicit_Allocations mdn page] for more details.<br />
<br />
=== Images summary ===<br />
<br />
* This is a subset of the "explicit" measurement that focuses on memory used to render images.<br />
<br />
==== Possible regression causes ====<br />
* A regressions in this can indicate leaks or poor memory usage in the image subsystem. In the past this was persistent problem.<br />
<br />
=== JS summary ===<br />
<br />
* This is the "js-main-runtime/" value in about:memory which is all the memory attributed to the javascript engine.<br />
<br />
==== Possible regression causes ====<br />
* A regression in this number can indicate leaks in the JS engine, optimizations that take performance into consideration at the expense of more memory, or problems with the garbage collector.<br />
<br />
=== Resident Memory summary ===<br />
<br />
* This is a higher level measurement provided by the operating system. We sum the "resident" memory ([https://en.wikipedia.org/wiki/Resident_set_size RSS]) with the [https://en.wikipedia.org/wiki/Unique_set_size resident-unique] memory of the content processes. It's pretty noisy and large so it's not very useful in detecting smaller regressions.<br />
<br />
==== Possible regression causes ====<br />
* Regressions in this often track regressions in explicit and heap unclassified. If we see a regression in resident, but not in other reports this can indicate we are leaking untracked memory (perhaps through shared memory, graphics allocations, file handles, etc).<br />
<br />
=== Other references ===<br />
[https://developer.mozilla.org/en-US/docs/Mozilla/Performance/AWSY Are We Slim Yet MDN web docs]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1224684Oxidation2020-03-05T22:53:47Z<p>Nnethercote: /* Outside Firefox */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more productive to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety. Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
* High performance. In particular, the safety enables code that is designed more actively for performance, especially parallel performance.<br />
* Nimbleness. The safety enables significant changes to existing code to be made quickly and with confidence.<br />
* Expressiveness. It is powerful and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent package management and an extensive ecosystem.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A friendly and helpful community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating. (The new borrow checker released in Rust 1.31 helped greatly with this.)<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* [https://crisal.io/words/2020/02/28/C++-rust-ffi-patterns-1-complex-data-structures.html FFI patterns #1 - Complex Rust data structures exposed seamlessly to C++]<br />
* The Rust channel on [https://wiki.mozilla.org/Matrix Mozilla's Matrix network] contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central?<br /><br />
<br />
'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.<br />
<br />
<br />
'''Q:''' Do we support building standalone Rust programs?<br /><br />
<br />
'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.<br />
<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* libcubeb Audio backend for Linux (PulseAudio): {{bug|1346665}} (shipped in Firefox 59)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety assist productivity, and allow more aggressive optimizations.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* Profiler symbolication: {{bug|1509549}} (shipped in Firefox 67)<br />
** '''Why Rust?''' Makes use of existing crates that handle object file parsing and symbol iteration. Easy to compile to WebAssembly.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* [https://github.com/padenot/audio_thread_priority audio_thread_priority] {{bug|1429847}} (shipped in Firefox 69), allow promoting threads to a real-time scheduling class, on Windows/Linux/macOS.<br />
** '''Why Rust?''' This crate is being used by C++ code and by Rust code (audioipc), Rust is nicer to write than C++ (especially for what is essentially just a series of system calls, the error checking style is nice), and cbindgen made it trivial to expose a C ABI.<br />
* [https://github.com/mozilla/dogear/ Dogear] a bookmark merger for Sync. Shipped pref'd-off in {{bug|1482608}} (Firefox 68), enabled by default in {{bug|1588005}} (shipped in Firefox 72)<br />
** '''Why Rust?''' A single performant and safe implementation shared between desktop and the bookmarks engine in [https://github.com/mozilla/application-services/tree/master/components/places application-services]<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Replace libhyphen with mapped_hyph, {{bug|1590167}} (shipped in Firefox 72).<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
<br />
=== In progress ===<br />
<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend Project Visage] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues. This also allows us to tailor the SDP parser specifically for the subset used in WebRTC, further reducing its surface area. It is currently run in parallel with the C parser in Nightly.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* libcubeb Audio backend for macOS (CoreAudio): {{bug|1530715}} (in Nightly since 70?)<br />
* [https://github.com/gfx-rs/wgpu wgpu], a [https://gpuweb.github.io/gpuweb/ WebGPU] API implementation: {{bug|webgpu-mvp}} (in Nightly since 72)<br />
** '''Why Rust?''' Complex tracking logic, wide attack area. Also, leverages Rust ecosystem for building libraries on top of our native implementation and the API that will target the Web.<br />
* Integrate the [https://github.com/mozilla/glean/ Glean SDK], a data collection library.<br />
<br />
=== Proposed ===<br />
<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
* [https://github.com/mozilla/application-services Sync/FxA components]<br />
** '''Why Rust?''' Single safe and performant implementation which is shared across all our products.<br />
* libcubeb Audio backend for Windows (WASAPI)<br />
* Replace the XML parser, possibly via c2rust: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
* Rewrite the ICE stack used by WebRTC; {{bug|1616966}}<br />
** '''Why Rust?''' Works with network data.<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
** [https://github.com/mozilla/dump_syms/ dump_syms], a reimplementation of Google Breakpad's dump_syms tool for Windows. Used to parse PDB files and print out Breakpad-compatible symbol files. <br />
*** '''Why Rust?''' Doesn't rely on Microsoft closed-source libraries anymore, can be cross-compiled and run on a non-Windows host, is an order of magnitude faster, takes less than a third of the memory, produces better symbols and relies on an active and friendly upstream [https://github.com/getsentry/symbolic/ symbolic]<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/components various sync-related components used on iOS and Fenix], includes a cross-compiled FxA Rust client, and storage/syncing of bookmarks, history, logins, tabs and webextensions data.<br />
* [https://github.com/mozilla/fix-stacks/ fix-stacks], a stack frame symbolizer: {{bug|1596292}}<br />
** '''Why Rust?''' High performance needed, a single implementation can replace multiple platform-specific scripts, and we can use the [https://github.com/getsentry/symbolic/ symbolic] crate to do all the hard parts.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* Berlin, January 2020 (minutes lost due to technical issues, unfortunately)<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1224552Oxidation2020-03-04T05:17:58Z<p>Nnethercote: /* Rust in Firefox */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more productive to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety. Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
* High performance. In particular, the safety enables code that is designed more actively for performance, especially parallel performance.<br />
* Nimbleness. The safety enables significant changes to existing code to be made quickly and with confidence.<br />
* Expressiveness. It is powerful and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent package management and an extensive ecosystem.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A friendly and helpful community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating. (The new borrow checker released in Rust 1.31 helped greatly with this.)<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* [https://crisal.io/words/2020/02/28/C++-rust-ffi-patterns-1-complex-data-structures.html FFI patterns #1 - Complex Rust data structures exposed seamlessly to C++]<br />
* The Rust channel on [https://wiki.mozilla.org/Matrix Mozilla's Matrix network] contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central?<br /><br />
<br />
'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.<br />
<br />
<br />
'''Q:''' Do we support building standalone Rust programs?<br /><br />
<br />
'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.<br />
<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* libcubeb Audio backend for Linux (PulseAudio): {{bug|1346665}} (shipped in Firefox 59)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety assist productivity, and allow more aggressive optimizations.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* Profiler symbolication: {{bug|1509549}} (shipped in Firefox 67)<br />
** '''Why Rust?''' Makes use of existing crates that handle object file parsing and symbol iteration. Easy to compile to WebAssembly.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* [https://github.com/padenot/audio_thread_priority audio_thread_priority] {{bug|1429847}} (shipped in Firefox 69), allow promoting threads to a real-time scheduling class, on Windows/Linux/macOS.<br />
** '''Why Rust?''' This crate is being used by C++ code and by Rust code (audioipc), Rust is nicer to write than C++ (especially for what is essentially just a series of system calls, the error checking style is nice), and cbindgen made it trivial to expose a C ABI.<br />
* [https://github.com/mozilla/dogear/ Dogear] a bookmark merger for Sync. Shipped pref'd-off in {{bug|1482608}} (Firefox 68), enabled by default in {{bug|1588005}} (shipped in Firefox 72)<br />
** '''Why Rust?''' A single performant and safe implementation shared between desktop and the bookmarks engine in [https://github.com/mozilla/application-services/tree/master/components/places application-services]<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Replace libhyphen with mapped_hyph, {{bug|1590167}} (shipped in Firefox 72).<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
<br />
=== In progress ===<br />
<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend Project Visage] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues. This also allows us to tailor the SDP parser specifically for the subset used in WebRTC, further reducing its surface area. It is currently run in parallel with the C parser in Nightly.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* libcubeb Audio backend for macOS (CoreAudio): {{bug|1530715}} (in Nightly since 70?)<br />
* [https://github.com/gfx-rs/wgpu wgpu], a [https://gpuweb.github.io/gpuweb/ WebGPU] API implementation: {{bug|webgpu-mvp}} (in Nightly since 72)<br />
** '''Why Rust?''' Complex tracking logic, wide attack area. Also, leverages Rust ecosystem for building libraries on top of our native implementation and the API that will target the Web.<br />
* Integrate the [https://github.com/mozilla/glean/ Glean SDK], a data collection library.<br />
<br />
=== Proposed ===<br />
<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
* [https://github.com/mozilla/application-services Sync/FxA components]<br />
** '''Why Rust?''' Single safe and performant implementation which is shared across all our products.<br />
* libcubeb Audio backend for Windows (WASAPI)<br />
* Replace the XML parser, possibly via c2rust: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
* Rewrite the ICE stack used by WebRTC; {{bug|1616966}}<br />
** '''Why Rust?''' Works with network data.<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
** [https://github.com/mozilla/dump_syms/ dump_syms], a reimplementation of Google Breakpad's dump_syms tool for Windows. Used to parse PDB files and print out Breakpad-compatible symbol files. <br />
*** '''Why Rust?''' Doesn't rely on Microsoft closed-source libraries anymore, can be cross-compiled and run on a non-Windows host, is an order of magnitude faster, takes less than a third of the memory, produces better symbols and relies on an active and friendly upstream [https://github.com/getsentry/symbolic/ symbolic]<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/components various sync-related components used on iOS and Fenix], includes a cross-compiled FxA Rust client, and storage/syncing of bookmarks, history, logins, tabs and webextensions data.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
* [https://github.com/mozilla/fix-stacks/ fix-stacks], a stack frame symbolizer: {{bug|1596292}}<br />
** '''Why Rust?''' High performance needed, a single implementation can replace multiple platform-specific scripts, and we can use the [https://github.com/getsentry/symbolic/ symbolic] crate to do all the hard parts.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* Berlin, January 2020 (minutes lost due to technical issues, unfortunately)<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1224551Oxidation2020-03-04T05:16:45Z<p>Nnethercote: /* Rust in Firefox */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more productive to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety. Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
* High performance. In particular, the safety enables code that is designed more actively for performance, especially parallel performance.<br />
* Nimbleness. The safety enables significant changes to existing code to be made quickly and with confidence.<br />
* Expressiveness. It is powerful and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent package management and an extensive ecosystem.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A friendly and helpful community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating. (The new borrow checker released in Rust 1.31 helped greatly with this.)<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* [https://crisal.io/words/2020/02/28/C++-rust-ffi-patterns-1-complex-data-structures.html FFI patterns #1 - Complex Rust data structures exposed seamlessly to C++]<br />
* The Rust Matrix channel contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central?<br /><br />
<br />
'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.<br />
<br />
<br />
'''Q:''' Do we support building standalone Rust programs?<br /><br />
<br />
'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.<br />
<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* libcubeb Audio backend for Linux (PulseAudio): {{bug|1346665}} (shipped in Firefox 59)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety assist productivity, and allow more aggressive optimizations.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* Profiler symbolication: {{bug|1509549}} (shipped in Firefox 67)<br />
** '''Why Rust?''' Makes use of existing crates that handle object file parsing and symbol iteration. Easy to compile to WebAssembly.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* [https://github.com/padenot/audio_thread_priority audio_thread_priority] {{bug|1429847}} (shipped in Firefox 69), allow promoting threads to a real-time scheduling class, on Windows/Linux/macOS.<br />
** '''Why Rust?''' This crate is being used by C++ code and by Rust code (audioipc), Rust is nicer to write than C++ (especially for what is essentially just a series of system calls, the error checking style is nice), and cbindgen made it trivial to expose a C ABI.<br />
* [https://github.com/mozilla/dogear/ Dogear] a bookmark merger for Sync. Shipped pref'd-off in {{bug|1482608}} (Firefox 68), enabled by default in {{bug|1588005}} (shipped in Firefox 72)<br />
** '''Why Rust?''' A single performant and safe implementation shared between desktop and the bookmarks engine in [https://github.com/mozilla/application-services/tree/master/components/places application-services]<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Replace libhyphen with mapped_hyph, {{bug|1590167}} (shipped in Firefox 72).<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
<br />
=== In progress ===<br />
<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend Project Visage] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues. This also allows us to tailor the SDP parser specifically for the subset used in WebRTC, further reducing its surface area. It is currently run in parallel with the C parser in Nightly.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* libcubeb Audio backend for macOS (CoreAudio): {{bug|1530715}} (in Nightly since 70?)<br />
* [https://github.com/gfx-rs/wgpu wgpu], a [https://gpuweb.github.io/gpuweb/ WebGPU] API implementation: {{bug|webgpu-mvp}} (in Nightly since 72)<br />
** '''Why Rust?''' Complex tracking logic, wide attack area. Also, leverages Rust ecosystem for building libraries on top of our native implementation and the API that will target the Web.<br />
* Integrate the [https://github.com/mozilla/glean/ Glean SDK], a data collection library.<br />
<br />
=== Proposed ===<br />
<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
* [https://github.com/mozilla/application-services Sync/FxA components]<br />
** '''Why Rust?''' Single safe and performant implementation which is shared across all our products.<br />
* libcubeb Audio backend for Windows (WASAPI)<br />
* Replace the XML parser, possibly via c2rust: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
* Rewrite the ICE stack used by WebRTC; {{bug|1616966}}<br />
** '''Why Rust?''' Works with network data.<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
** [https://github.com/mozilla/dump_syms/ dump_syms], a reimplementation of Google Breakpad's dump_syms tool for Windows. Used to parse PDB files and print out Breakpad-compatible symbol files. <br />
*** '''Why Rust?''' Doesn't rely on Microsoft closed-source libraries anymore, can be cross-compiled and run on a non-Windows host, is an order of magnitude faster, takes less than a third of the memory, produces better symbols and relies on an active and friendly upstream [https://github.com/getsentry/symbolic/ symbolic]<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/components various sync-related components used on iOS and Fenix], includes a cross-compiled FxA Rust client, and storage/syncing of bookmarks, history, logins, tabs and webextensions data.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
* [https://github.com/mozilla/fix-stacks/ fix-stacks], a stack frame symbolizer: {{bug|1596292}}<br />
** '''Why Rust?''' High performance needed, a single implementation can replace multiple platform-specific scripts, and we can use the [https://github.com/getsentry/symbolic/ symbolic] crate to do all the hard parts.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* Berlin, January 2020 (minutes lost due to technical issues, unfortunately)<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1224007Oxidation2020-02-20T03:08:58Z<p>Nnethercote: /* Rust Strengths */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more productive to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety. Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
* High performance. In particular, the safety enables code that is designed more actively for performance, especially parallel performance.<br />
* Nimbleness. The safety enables significant changes to existing code to be made quickly and with confidence.<br />
* Expressiveness. It is powerful and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent package management and an extensive ecosystem.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A friendly and helpful community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating. (The new borrow checker released in Rust 1.31 helped greatly with this.)<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* The Rust Matrix channel contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central?<br /><br />
<br />
'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.<br />
<br />
<br />
'''Q:''' Do we support building standalone Rust programs?<br /><br />
<br />
'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.<br />
<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* libcubeb Audio backend for Linux (PulseAudio): {{bug|1346665}} (shipped in Firefox 59)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety assist productivity, and allow more aggressive optimizations.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* [https://github.com/padenot/audio_thread_priority audio_thread_priority] {{bug|1429847}} (shipped in Firefox 69), allow promoting threads to a real-time scheduling class, on Windows/Linux/macOS.<br />
** '''Why Rust?''' This crate is being used by C++ code and by Rust code (audioipc), Rust is nicer to write than C++ (especially for what is essentially just a series of system calls, the error checking style is nice), and cbindgen made it trivial to expose a C ABI.<br />
* [https://github.com/mozilla/dogear/ Dogear] a bookmark merger for Sync. Shipped pref'd-off in {{bug|1482608}} (Firefox 68), enabled by default in {{bug|1588005}} (shipped in Firefox 72)<br />
** '''Why Rust?''' A single performant and safe implementation shared between desktop and the bookmarks engine in [https://github.com/mozilla/application-services/tree/master/components/places application-services]<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Replace libhyphen with mapped_hyph, {{bug|1590167}} (shipped in Firefox 72).<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
<br />
=== In progress ===<br />
<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend Project Visage] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues. This also allows us to tailor the SDP parser specifically for the subset used in WebRTC, further reducing its surface area. It is currently run in parallel with the C parser in Nightly.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* libcubeb Audio backend for macOS (CoreAudio): {{bug|1530715}} (in Nightly since 70?)<br />
* [https://github.com/gfx-rs/wgpu wgpu], a [https://gpuweb.github.io/gpuweb/ WebGPU] API implementation: {{bug|webgpu-mvp}} (in Nightly since 72)<br />
** '''Why Rust?''' Complex tracking logic, wide attack area. Also, leverages Rust ecosystem for building libraries on top of our native implementation and the API that will target the Web.<br />
<br />
=== Proposed ===<br />
<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
* [https://github.com/mozilla/application-services Sync/FxA components]<br />
** '''Why Rust?''' Single safe and performant implementation which is shared across all our products.<br />
* libcubeb Audio backend for Windows (WASAPI)<br />
* Replace the XML parser, possibly via c2rust: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
** [https://github.com/mozilla/dump_syms/ dump_syms], a reimplementation of Google Breakpad's dump_syms tool for Windows. Used to parse PDB files and print out Breakpad-compatible symbol files. <br />
*** '''Why Rust?''' Doesn't rely on Microsoft closed-source libraries anymore, can be cross-compiled and run on a non-Windows host, is an order of magnitude faster, takes less than a third of the memory, produces better symbols and relies on an active and friendly upstream [https://github.com/getsentry/symbolic/ symbolic]<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/components various sync-related components used on iOS and Fenix], includes a cross-compiled FxA Rust client, and storage/syncing of bookmarks, history, logins, tabs and webextensions data.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
* [https://github.com/mozilla/fix-stacks/ fix-stacks], a stack frame symbolizer: {{bug|1596292}}<br />
** '''Why Rust?''' High performance needed, a single implementation can replace multiple platform-specific scripts, and we can use the [https://github.com/getsentry/symbolic/ symbolic] crate to do all the hard parts.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* Berlin, January 2020 (minutes lost due to technical issues, unfortunately)<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1224005Oxidation2020-02-20T00:53:08Z<p>Nnethercote: /* Meetings */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more productive to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety. Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
* High performance. In particular, the safety enables code that is designed more actively for performance, especially parallel performance.<br />
* Nimbleness. The safety enables significant changes to existing code to be made quickly and with confidence.<br />
* Expressiveness. It is powerful and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A friendly and helpful community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating. (The new borrow checker released in Rust 1.31 helped greatly with this.)<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* The Rust Matrix channel contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central?<br /><br />
<br />
'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.<br />
<br />
<br />
'''Q:''' Do we support building standalone Rust programs?<br /><br />
<br />
'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.<br />
<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* libcubeb Audio backend for Linux (PulseAudio): {{bug|1346665}} (shipped in Firefox 59)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety assist productivity, and allow more aggressive optimizations.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* [https://github.com/padenot/audio_thread_priority audio_thread_priority] {{bug|1429847}} (shipped in Firefox 69), allow promoting threads to a real-time scheduling class, on Windows/Linux/macOS.<br />
** '''Why Rust?''' This crate is being used by C++ code and by Rust code (audioipc), Rust is nicer to write than C++ (especially for what is essentially just a series of system calls, the error checking style is nice), and cbindgen made it trivial to expose a C ABI.<br />
* [https://github.com/mozilla/dogear/ Dogear] a bookmark merger for Sync. Shipped pref'd-off in {{bug|1482608}} (Firefox 68), enabled by default in {{bug|1588005}} (shipped in Firefox 72)<br />
** '''Why Rust?''' A single performant and safe implementation shared between desktop and the bookmarks engine in [https://github.com/mozilla/application-services/tree/master/components/places application-services]<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Replace libhyphen with mapped_hyph, {{bug|1590167}} (shipped in Firefox 72).<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
<br />
=== In progress ===<br />
<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend Project Visage] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues. This also allows us to tailor the SDP parser specifically for the subset used in WebRTC, further reducing its surface area. It is currently run in parallel with the C parser in Nightly.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* libcubeb Audio backend for macOS (CoreAudio): {{bug|1530715}} (in Nightly since 70?)<br />
* [https://github.com/gfx-rs/wgpu wgpu], a [https://gpuweb.github.io/gpuweb/ WebGPU] API implementation: {{bug|webgpu-mvp}} (in Nightly since 72)<br />
** '''Why Rust?''' Complex tracking logic, wide attack area. Also, leverages Rust ecosystem for building libraries on top of our native implementation and the API that will target the Web.<br />
<br />
=== Proposed ===<br />
<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
* [https://github.com/mozilla/application-services Sync/FxA components]<br />
** '''Why Rust?''' Single safe and performant implementation which is shared across all our products.<br />
* libcubeb Audio backend for Windows (WASAPI)<br />
* Replace the XML parser, possibly via c2rust: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
** [https://github.com/mozilla/dump_syms/ dump_syms], a reimplementation of Google Breakpad's dump_syms tool for Windows. Used to parse PDB files and print out Breakpad-compatible symbol files. <br />
*** '''Why Rust?''' Doesn't rely on Microsoft closed-source libraries anymore, can be cross-compiled and run on a non-Windows host, is an order of magnitude faster, takes less than a third of the memory, produces better symbols and relies on an active and friendly upstream [https://github.com/getsentry/symbolic/ symbolic]<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/components various sync-related components used on iOS and Fenix], includes a cross-compiled FxA Rust client, and storage/syncing of bookmarks, history, logins, tabs and webextensions data.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
* [https://github.com/mozilla/fix-stacks/ fix-stacks], a stack frame symbolizer: {{bug|1596292}}<br />
** '''Why Rust?''' High performance needed, a single implementation can replace multiple platform-specific scripts, and we can use the [https://github.com/getsentry/symbolic/ symbolic] crate to do all the hard parts.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* Berlin, January 2020 (minutes lost due to technical issues, unfortunately)<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1224004Oxidation2020-02-20T00:52:17Z<p>Nnethercote: /* Meetings */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more productive to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety. Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
* High performance. In particular, the safety enables code that is designed more actively for performance, especially parallel performance.<br />
* Nimbleness. The safety enables significant changes to existing code to be made quickly and with confidence.<br />
* Expressiveness. It is powerful and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A friendly and helpful community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating. (The new borrow checker released in Rust 1.31 helped greatly with this.)<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* The Rust Matrix channel contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central?<br /><br />
<br />
'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.<br />
<br />
<br />
'''Q:''' Do we support building standalone Rust programs?<br /><br />
<br />
'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.<br />
<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* libcubeb Audio backend for Linux (PulseAudio): {{bug|1346665}} (shipped in Firefox 59)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety assist productivity, and allow more aggressive optimizations.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* [https://github.com/padenot/audio_thread_priority audio_thread_priority] {{bug|1429847}} (shipped in Firefox 69), allow promoting threads to a real-time scheduling class, on Windows/Linux/macOS.<br />
** '''Why Rust?''' This crate is being used by C++ code and by Rust code (audioipc), Rust is nicer to write than C++ (especially for what is essentially just a series of system calls, the error checking style is nice), and cbindgen made it trivial to expose a C ABI.<br />
* [https://github.com/mozilla/dogear/ Dogear] a bookmark merger for Sync. Shipped pref'd-off in {{bug|1482608}} (Firefox 68), enabled by default in {{bug|1588005}} (shipped in Firefox 72)<br />
** '''Why Rust?''' A single performant and safe implementation shared between desktop and the bookmarks engine in [https://github.com/mozilla/application-services/tree/master/components/places application-services]<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Replace libhyphen with mapped_hyph, {{bug|1590167}} (shipped in Firefox 72).<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
<br />
=== In progress ===<br />
<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend Project Visage] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues. This also allows us to tailor the SDP parser specifically for the subset used in WebRTC, further reducing its surface area. It is currently run in parallel with the C parser in Nightly.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* libcubeb Audio backend for macOS (CoreAudio): {{bug|1530715}} (in Nightly since 70?)<br />
* [https://github.com/gfx-rs/wgpu wgpu], a [https://gpuweb.github.io/gpuweb/ WebGPU] API implementation: {{bug|webgpu-mvp}} (in Nightly since 72)<br />
** '''Why Rust?''' Complex tracking logic, wide attack area. Also, leverages Rust ecosystem for building libraries on top of our native implementation and the API that will target the Web.<br />
<br />
=== Proposed ===<br />
<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
* [https://github.com/mozilla/application-services Sync/FxA components]<br />
** '''Why Rust?''' Single safe and performant implementation which is shared across all our products.<br />
* libcubeb Audio backend for Windows (WASAPI)<br />
* Replace the XML parser, possibly via c2rust: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
** [https://github.com/mozilla/dump_syms/ dump_syms], a reimplementation of Google Breakpad's dump_syms tool for Windows. Used to parse PDB files and print out Breakpad-compatible symbol files. <br />
*** '''Why Rust?''' Doesn't rely on Microsoft closed-source libraries anymore, can be cross-compiled and run on a non-Windows host, is an order of magnitude faster, takes less than a third of the memory, produces better symbols and relies on an active and friendly upstream [https://github.com/getsentry/symbolic/ symbolic]<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/components various sync-related components used on iOS and Fenix], includes a cross-compiled FxA Rust client, and storage/syncing of bookmarks, history, logins, tabs and webextensions data.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
* [https://github.com/mozilla/fix-stacks/ fix-stacks], a stack frame symbolizer: {{bug|1596292}}<br />
** '''Why Rust?''' High performance needed, a single implementation can replace multiple platform-specific scripts, and we can use the [https://github.com/getsentry/symbolic/ symbolic] crate to do all the hard parts.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* Berlin, January 2020 (minutes lost due to an expired etherpad, unfortunately)<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1224003Oxidation2020-02-20T00:43:48Z<p>Nnethercote: </p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more productive to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety. Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
* High performance. In particular, the safety enables code that is designed more actively for performance, especially parallel performance.<br />
* Nimbleness. The safety enables significant changes to existing code to be made quickly and with confidence.<br />
* Expressiveness. It is powerful and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A friendly and helpful community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating. (The new borrow checker released in Rust 1.31 helped greatly with this.)<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* The Rust Matrix channel contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central?<br /><br />
<br />
'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.<br />
<br />
<br />
'''Q:''' Do we support building standalone Rust programs?<br /><br />
<br />
'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.<br />
<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* libcubeb Audio backend for Linux (PulseAudio): {{bug|1346665}} (shipped in Firefox 59)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety assist productivity, and allow more aggressive optimizations.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* [https://github.com/padenot/audio_thread_priority audio_thread_priority] {{bug|1429847}} (shipped in Firefox 69), allow promoting threads to a real-time scheduling class, on Windows/Linux/macOS.<br />
** '''Why Rust?''' This crate is being used by C++ code and by Rust code (audioipc), Rust is nicer to write than C++ (especially for what is essentially just a series of system calls, the error checking style is nice), and cbindgen made it trivial to expose a C ABI.<br />
* [https://github.com/mozilla/dogear/ Dogear] a bookmark merger for Sync. Shipped pref'd-off in {{bug|1482608}} (Firefox 68), enabled by default in {{bug|1588005}} (shipped in Firefox 72)<br />
** '''Why Rust?''' A single performant and safe implementation shared between desktop and the bookmarks engine in [https://github.com/mozilla/application-services/tree/master/components/places application-services]<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Replace libhyphen with mapped_hyph, {{bug|1590167}} (shipped in Firefox 72).<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
<br />
=== In progress ===<br />
<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend Project Visage] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues. This also allows us to tailor the SDP parser specifically for the subset used in WebRTC, further reducing its surface area. It is currently run in parallel with the C parser in Nightly.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* libcubeb Audio backend for macOS (CoreAudio): {{bug|1530715}} (in Nightly since 70?)<br />
* [https://github.com/gfx-rs/wgpu wgpu], a [https://gpuweb.github.io/gpuweb/ WebGPU] API implementation: {{bug|webgpu-mvp}} (in Nightly since 72)<br />
** '''Why Rust?''' Complex tracking logic, wide attack area. Also, leverages Rust ecosystem for building libraries on top of our native implementation and the API that will target the Web.<br />
<br />
=== Proposed ===<br />
<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
* [https://github.com/mozilla/application-services Sync/FxA components]<br />
** '''Why Rust?''' Single safe and performant implementation which is shared across all our products.<br />
* libcubeb Audio backend for Windows (WASAPI)<br />
* Replace the XML parser, possibly via c2rust: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
** [https://github.com/mozilla/dump_syms/ dump_syms], a reimplementation of Google Breakpad's dump_syms tool for Windows. Used to parse PDB files and print out Breakpad-compatible symbol files. <br />
*** '''Why Rust?''' Doesn't rely on Microsoft closed-source libraries anymore, can be cross-compiled and run on a non-Windows host, is an order of magnitude faster, takes less than a third of the memory, produces better symbols and relies on an active and friendly upstream [https://github.com/getsentry/symbolic/ symbolic]<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/components various sync-related components used on iOS and Fenix], includes a cross-compiled FxA Rust client, and storage/syncing of bookmarks, history, logins, tabs and webextensions data.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
* [https://github.com/mozilla/fix-stacks/ fix-stacks], a stack frame symbolizer: {{bug|1596292}}<br />
** '''Why Rust?''' High performance needed, a single implementation can replace multiple platform-specific scripts, and we can use the [https://github.com/getsentry/symbolic/ symbolic] crate to do all the hard parts.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1224002Oxidation2020-02-20T00:41:14Z<p>Nnethercote: /* In Progress */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more pleasant to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety.<br />
** Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
** The safety guarantees allow code that is designed more actively for performance, especially parallel performance.<br />
** The safety guarantees allow significant changes to existing code to be made quickly and with confidence.<br />
* Expressive and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A friendly and helpful community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating. (The new borrow checker released in Rust 1.31 helped greatly with this.)<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* The Rust Matrix channel contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central?<br /><br />
<br />
'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.<br />
<br />
<br />
'''Q:''' Do we support building standalone Rust programs?<br /><br />
<br />
'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.<br />
<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* libcubeb Audio backend for Linux (PulseAudio): {{bug|1346665}} (shipped in Firefox 59)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety assist productivity, and allow more aggressive optimizations.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* [https://github.com/padenot/audio_thread_priority audio_thread_priority] {{bug|1429847}} (shipped in Firefox 69), allow promoting threads to a real-time scheduling class, on Windows/Linux/macOS.<br />
** '''Why Rust?''' This crate is being used by C++ code and by Rust code (audioipc), Rust is nicer to write than C++ (especially for what is essentially just a series of system calls, the error checking style is nice), and cbindgen made it trivial to expose a C ABI.<br />
* [https://github.com/mozilla/dogear/ Dogear] a bookmark merger for Sync. Shipped pref'd-off in {{bug|1482608}} (Firefox 68), enabled by default in {{bug|1588005}} (shipped in Firefox 72)<br />
** '''Why Rust?''' A single performant and safe implementation shared between desktop and the bookmarks engine in [https://github.com/mozilla/application-services/tree/master/components/places application-services]<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Replace libhyphen with mapped_hyph, {{bug|1590167}} (shipped in Firefox 72).<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
<br />
=== In progress ===<br />
<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend Project Visage] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues. This also allows us to tailor the SDP parser specifically for the subset used in WebRTC, further reducing its surface area. It is currently run in parallel with the C parser in Nightly.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* libcubeb Audio backend for macOS (CoreAudio): {{bug|1530715}} (in Nightly since 70?)<br />
* [https://github.com/gfx-rs/wgpu wgpu], a [https://gpuweb.github.io/gpuweb/ WebGPU] API implementation: {{bug|webgpu-mvp}} (in Nightly since 72)<br />
** '''Why Rust?''' Complex tracking logic, wide attack area. Also, leverages Rust ecosystem for building libraries on top of our native implementation and the API that will target the Web.<br />
<br />
=== Proposed ===<br />
<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
* [https://github.com/mozilla/application-services Sync/FxA components]<br />
** '''Why Rust?''' Single safe and performant implementation which is shared across all our products.<br />
* libcubeb Audio backend for Windows (WASAPI)<br />
* Replace the XML parser, possibly via c2rust: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
** [https://github.com/mozilla/dump_syms/ dump_syms], a reimplementation of Google Breakpad's dump_syms tool for Windows. Used to parse PDB files and print out Breakpad-compatible symbol files. <br />
*** '''Why Rust?''' Doesn't rely on Microsoft closed-source libraries anymore, can be cross-compiled and run on a non-Windows host, is an order of magnitude faster, takes less than a third of the memory, produces better symbols and relies on an active and friendly upstream [https://github.com/getsentry/symbolic/ symbolic]<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/components various sync-related components used on iOS and Fenix], includes a cross-compiled FxA Rust client, and storage/syncing of bookmarks, history, logins, tabs and webextensions data.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
* [https://github.com/mozilla/fix-stacks/ fix-stacks], a stack frame symbolizer: {{bug|1596292}}<br />
** '''Why Rust?''' High performance needed, a single implementation can replace multiple platform-specific scripts, and we can use the [https://github.com/getsentry/symbolic/ symbolic] crate to do all the hard parts.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1224001Oxidation2020-02-20T00:37:07Z<p>Nnethercote: /* In Progress */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more pleasant to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety.<br />
** Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
** The safety guarantees allow code that is designed more actively for performance, especially parallel performance.<br />
** The safety guarantees allow significant changes to existing code to be made quickly and with confidence.<br />
* Expressive and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A friendly and helpful community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating. (The new borrow checker released in Rust 1.31 helped greatly with this.)<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* The Rust Matrix channel contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central?<br /><br />
<br />
'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.<br />
<br />
<br />
'''Q:''' Do we support building standalone Rust programs?<br /><br />
<br />
'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.<br />
<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* libcubeb Audio backend for Linux (PulseAudio): {{bug|1346665}} (shipped in Firefox 59)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety assist productivity, and allow more aggressive optimizations.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* [https://github.com/padenot/audio_thread_priority audio_thread_priority] {{bug|1429847}} (shipped in Firefox 69), allow promoting threads to a real-time scheduling class, on Windows/Linux/macOS.<br />
** '''Why Rust?''' This crate is being used by C++ code and by Rust code (audioipc), Rust is nicer to write than C++ (especially for what is essentially just a series of system calls, the error checking style is nice), and cbindgen made it trivial to expose a C ABI.<br />
* [https://github.com/mozilla/dogear/ Dogear] a bookmark merger for Sync. Shipped pref'd-off in {{bug|1482608}} (Firefox 68), enabled by default in {{bug|1588005}} (shipped in Firefox 72)<br />
** '''Why Rust?''' A single performant and safe implementation shared between desktop and the bookmarks engine in [https://github.com/mozilla/application-services/tree/master/components/places application-services]<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Replace libhyphen with mapped_hyph, {{bug|1590167}} (shipped in Firefox 72).<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
<br />
=== In progress ===<br />
<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend Project Visage] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues. This also allows us to tailor the SDP parser specifically for the subset used in WebRTC, further reducing its surface area. It is currently run in parallel with the C parser in Nightly.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* libcubeb Audio backend for macOS (CoreAudio): {{bug|1530715}} (in Nightly since 70?)<br />
* [https://github.com/gfx-rs/wgpu wgpu], a [https://gpuweb.github.io/gpuweb/ WebGPU] API implementation: {{bug|webgpu-mvp}} (in Nightly since 72)<br />
** '''Why Rust?''' Complex tracking logic, wide attack area. Also, leverages Rust ecosystem for building libraries on top of our native implementation and the API that will target the Web.<br />
<br />
=== Proposed ===<br />
<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
* [https://github.com/mozilla/application-services Sync/FxA components]<br />
** '''Why Rust?''' Single safe and performant implementation which is shared across all our products.<br />
* libcubeb Audio backend for Windows (WASAPI)<br />
* Replace the XML parser, possibly via c2rust: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
** [https://github.com/mozilla/dump_syms/ dump_syms], a reimplementation of Google Breakpad's dump_syms tool for Windows. Used to parse PDB files and print out Breakpad-compatible symbol files. <br />
*** '''Why Rust?''' Doesn't rely on Microsoft closed-source libraries anymore, can be cross-compiled and run on a non-Windows host, is an order of magnitude faster, takes less than a third of the memory, produces better symbols and relies on an active and friendly upstream [https://github.com/getsentry/symbolic/ symbolic]<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/components various sync-related components used on iOS and Fenix], includes a cross-compiled FxA Rust client, and storage/syncing of bookmarks, history, logins, tabs and webextensions data.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
* [https://github.com/mozilla/fix-stacks/ fix-stacks] (a stack frame symbolizer): {{bug|1596292}}<br />
** '''Why Rust?''' High performance needed, a single implementation can replace multiple platform-specific scripts, and we can use the [https://github.com/getsentry/symbolic/ symbolic] crate to do all the hard parts.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1224000Oxidation2020-02-20T00:29:56Z<p>Nnethercote: /* Within Firefox */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more pleasant to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety.<br />
** Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
** The safety guarantees allow code that is designed more actively for performance, especially parallel performance.<br />
** The safety guarantees allow significant changes to existing code to be made quickly and with confidence.<br />
* Expressive and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A friendly and helpful community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating. (The new borrow checker released in Rust 1.31 helped greatly with this.)<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* The Rust Matrix channel contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central?<br /><br />
<br />
'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.<br />
<br />
<br />
'''Q:''' Do we support building standalone Rust programs?<br /><br />
<br />
'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.<br />
<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* libcubeb Audio backend for Linux (PulseAudio): {{bug|1346665}} (shipped in Firefox 59)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety assist productivity, and allow more aggressive optimizations.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* [https://github.com/padenot/audio_thread_priority audio_thread_priority] {{bug|1429847}} (shipped in Firefox 69), allow promoting threads to a real-time scheduling class, on Windows/Linux/macOS.<br />
** '''Why Rust?''' This crate is being used by C++ code and by Rust code (audioipc), Rust is nicer to write than C++ (especially for what is essentially just a series of system calls, the error checking style is nice), and cbindgen made it trivial to expose a C ABI.<br />
* [https://github.com/mozilla/dogear/ Dogear] a bookmark merger for Sync. Shipped pref'd-off in {{bug|1482608}} (Firefox 68), enabled by default in {{bug|1588005}} (shipped in Firefox 72)<br />
** '''Why Rust?''' A single performant and safe implementation shared between desktop and the bookmarks engine in [https://github.com/mozilla/application-services/tree/master/components/places application-services]<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Replace libhyphen with mapped_hyph, {{bug|1590167}} (shipped in Firefox 72).<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
<br />
=== In progress ===<br />
<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend Project Visage] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues. This also allows us to tailor the SDP parser specifically for the subset used in WebRTC, further reducing its surface area. It is currently run in parallel with the C parser in Nightly.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* libcubeb Audio backend for macOS (CoreAudio): {{bug|1530715}} (in Nightly since 70?)<br />
* [https://github.com/gfx-rs/wgpu wgpu], a [https://gpuweb.github.io/gpuweb/ WebGPU] API implementation: {{bug|webgpu-mvp}} (in Nightly since 72)<br />
** '''Why Rust?''' Complex tracking logic, wide attack area. Also, leverages Rust ecosystem for building libraries on top of our native implementation and the API that will target the Web.<br />
<br />
=== Proposed ===<br />
<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
* [https://github.com/mozilla/application-services Sync/FxA components]<br />
** '''Why Rust?''' Single safe and performant implementation which is shared across all our products.<br />
* libcubeb Audio backend for Windows (WASAPI)<br />
* Replace the XML parser, possibly via c2rust: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
** [https://github.com/mozilla/dump_syms/ dump_syms], a reimplementation of Google Breakpad's dump_syms tool for Windows. Used to parse PDB files and print out Breakpad-compatible symbol files. <br />
*** '''Why Rust?''' Doesn't rely on Microsoft closed-source libraries anymore, can be cross-compiled and run on a non-Windows host, is an order of magnitude faster, takes less than a third of the memory, produces better symbols and relies on an active and friendly upstream [https://github.com/getsentry/symbolic/ symbolic]<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/components various sync-related components used on iOS and Fenix], includes a cross-compiled FxA Rust client, and storage/syncing of bookmarks, history, logins, tabs and webextensions data.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1223999Oxidation2020-02-20T00:28:22Z<p>Nnethercote: /* Shipped */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more pleasant to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety.<br />
** Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
** The safety guarantees allow code that is designed more actively for performance, especially parallel performance.<br />
** The safety guarantees allow significant changes to existing code to be made quickly and with confidence.<br />
* Expressive and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A friendly and helpful community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating. (The new borrow checker released in Rust 1.31 helped greatly with this.)<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* The Rust Matrix channel contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central?<br /><br />
<br />
'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.<br />
<br />
<br />
'''Q:''' Do we support building standalone Rust programs?<br /><br />
<br />
'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.<br />
<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* libcubeb Audio backend for Linux (PulseAudio): {{bug|1346665}} (shipped in Firefox 59)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety assist productivity, and allow more aggressive optimizations.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* [https://github.com/padenot/audio_thread_priority audio_thread_priority] {{bug|1429847}} (shipped in Firefox 69), allow promoting threads to a real-time scheduling class, on Windows/Linux/macOS.<br />
** '''Why Rust?''' This crate is being used by C++ code and by Rust code (audioipc), Rust is nicer to write than C++ (especially for what is essentially just a series of system calls, the error checking style is nice), and cbindgen made it trivial to expose a C ABI.<br />
* [https://github.com/mozilla/dogear/ Dogear] a bookmark merger for Sync. Shipped pref'd-off in {{bug|1482608}} (Firefox 68), enabled by default in {{bug|1588005}} (shipped in Firefox 72)<br />
** '''Why Rust?''' A single performant and safe implementation shared between desktop and the bookmarks engine in [https://github.com/mozilla/application-services/tree/master/components/places application-services]<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Replace libhyphen with mapped_hyph, {{bug|1590167}} (shipped in Firefox 72).<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
<br />
=== In progress ===<br />
<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend Project Visage] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues. This also allows us to tailor the SDP parser specifically for the subset used in WebRTC, further reducing its surface area. It is currently run in parallel with the C parser in Nightly.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* Replace the XML parser: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
* libcubeb Audio backend for macOS (CoreAudio): {{bug|1530715}} (in Nightly since 70?)<br />
* [https://github.com/gfx-rs/wgpu wgpu], a [https://gpuweb.github.io/gpuweb/ WebGPU] API implementation: {{bug|webgpu-mvp}} (in Nightly since 72)<br />
** '''Why Rust?''' Complex tracking logic, wide attack area. Also, leverages Rust ecosystem for building libraries on top of our native implementation and the API that will target the Web.<br />
<br />
=== Proposed ===<br />
<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
* [https://github.com/mozilla/application-services Sync/FxA components]<br />
** '''Why Rust?''' Single safe and performant implementation which is shared across all our products.<br />
* libcubeb Audio backend for Windows (WASAPI)<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
** [https://github.com/mozilla/dump_syms/ dump_syms], a reimplementation of Google Breakpad's dump_syms tool for Windows. Used to parse PDB files and print out Breakpad-compatible symbol files. <br />
*** '''Why Rust?''' Doesn't rely on Microsoft closed-source libraries anymore, can be cross-compiled and run on a non-Windows host, is an order of magnitude faster, takes less than a third of the memory, produces better symbols and relies on an active and friendly upstream [https://github.com/getsentry/symbolic/ symbolic]<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/components various sync-related components used on iOS and Fenix], includes a cross-compiled FxA Rust client, and storage/syncing of bookmarks, history, logins, tabs and webextensions data.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1223998Oxidation2020-02-20T00:26:12Z<p>Nnethercote: /* Rust Components */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more pleasant to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety.<br />
** Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
** The safety guarantees allow code that is designed more actively for performance, especially parallel performance.<br />
** The safety guarantees allow significant changes to existing code to be made quickly and with confidence.<br />
* Expressive and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A friendly and helpful community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating. (The new borrow checker released in Rust 1.31 helped greatly with this.)<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* The Rust Matrix channel contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central?<br /><br />
<br />
'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.<br />
<br />
<br />
'''Q:''' Do we support building standalone Rust programs?<br /><br />
<br />
'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.<br />
<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* libcubeb Audio backend for Linux (PulseAudio): {{bug|1346665}} (shipped in Firefox 59)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety assist productivity, and allow more aggressive optimizations.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* [https://github.com/padenot/audio_thread_priority audio_thread_priority] {{bug|1429847}} (shipped in Firefox 69), allow promoting threads to a real-time scheduling class, on Windows/Linux/macOS.<br />
** '''Why Rust?''' This crate is being used by C++ code and by Rust code (audioipc), Rust is nicer to write than C++ (especially for what is essentially just a series of system calls, the error checking style is nice), and cbindgen made it trivial to expose a C ABI.<br />
* [https://github.com/mozilla/dogear/ Dogear] a bookmark merger for Sync. Shipped pref'd-off in {{bug|1482608}} (Firefox 68), enabled by default in {{bug|1588005}} (shipped in Firefox 72)<br />
** '''Why Rust?''' A single performant and safe implementation shared between desktop and the bookmarks engine in [https://github.com/mozilla/application-services/tree/master/components/places application-services]<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
<br />
<br />
=== In progress ===<br />
<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend Project Visage] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues. This also allows us to tailor the SDP parser specifically for the subset used in WebRTC, further reducing its surface area. It is currently run in parallel with the C parser in Nightly.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* Replace the XML parser: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
* libcubeb Audio backend for macOS (CoreAudio): {{bug|1530715}} (in Nightly since 70?)<br />
* [https://github.com/gfx-rs/wgpu wgpu], a [https://gpuweb.github.io/gpuweb/ WebGPU] API implementation: {{bug|webgpu-mvp}} (in Nightly since 72)<br />
** '''Why Rust?''' Complex tracking logic, wide attack area. Also, leverages Rust ecosystem for building libraries on top of our native implementation and the API that will target the Web.<br />
<br />
=== Proposed ===<br />
<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
* [https://github.com/mozilla/application-services Sync/FxA components]<br />
** '''Why Rust?''' Single safe and performant implementation which is shared across all our products.<br />
* libcubeb Audio backend for Windows (WASAPI)<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
** [https://github.com/mozilla/dump_syms/ dump_syms], a reimplementation of Google Breakpad's dump_syms tool for Windows. Used to parse PDB files and print out Breakpad-compatible symbol files. <br />
*** '''Why Rust?''' Doesn't rely on Microsoft closed-source libraries anymore, can be cross-compiled and run on a non-Windows host, is an order of magnitude faster, takes less than a third of the memory, produces better symbols and relies on an active and friendly upstream [https://github.com/getsentry/symbolic/ symbolic]<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/components various sync-related components used on iOS and Fenix], includes a cross-compiled FxA Rust client, and storage/syncing of bookmarks, history, logins, tabs and webextensions data.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1223996Oxidation2020-02-20T00:15:07Z<p>Nnethercote: /* Proposed */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more pleasant to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety.<br />
** Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
** The safety guarantees allow code that is designed more actively for performance, especially parallel performance.<br />
** The safety guarantees allow significant changes to existing code to be made quickly and with confidence.<br />
* Expressive and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A friendly and helpful community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating. (The new borrow checker released in Rust 1.31 helped greatly with this.)<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* The Rust Matrix channel contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central?<br /><br />
<br />
'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.<br />
<br />
<br />
'''Q:''' Do we support building standalone Rust programs?<br /><br />
<br />
'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.<br />
<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety provides protection against complexity.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
* [https://github.com/mozilla/dogear/ Dogear] a bookmark merger for Sync. Shipped pref'd-off in {{bug|1482608}} (Firefox 68), enabled by default in {{bug|1588005}} (Firefox 72)<br />
** '''Why Rust?''' A single performant and safe implementation which is shared between desktop and the bookmarks engine in [https://github.com/mozilla/application-services/tree/master/components/places application-services]<br />
* libcubeb Audio backend for Linux (PulseAudio): {{bug|1346665}} (shipped in Firefox 59)<br />
* [https://github.com/padenot/audio_thread_priority audio_thread_priority] {{bug|1429847}} (shipped in Firefox 69), allow promoting threads to a real-time scheduling class, on Windows/Linux/macOS.<br />
** '''Why Rust?''' This crate is being used by C++ code and by Rust code (audioipc), Rust is nicer to write than C++ (especially for what is essentially just a series of system calls, the error checking style is nice), and cbindgen made it trivial to expose a C ABI.<br />
<br />
<br />
=== In progress ===<br />
<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend Project Visage] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* Replace the XML parser: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
* libcubeb Audio backend for macOS (CoreAudio): {{bug|1530715}} (in Nightly since 70?)<br />
* [https://github.com/gfx-rs/wgpu wgpu], a [https://gpuweb.github.io/gpuweb/ WebGPU] API implementation: {{bug|webgpu-mvp}} (in Nightly since 72)<br />
** '''Why Rust?''' Complex tracking logic, wide attack area. Also, leverages Rust ecosystem for building libraries on top of our native implementation and the API that will target the Web.<br />
<br />
=== Proposed ===<br />
<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
* [https://github.com/mozilla/application-services Sync/FxA components]<br />
** '''Why Rust?''' Single safe and performant implementation which is shared across all our products.<br />
* libcubeb Audio backend for Windows (WASAPI)<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
** [https://github.com/mozilla/dump_syms/ dump_syms], a reimplementation of Google Breakpad's dump_syms tool for Windows. Used to parse PDB files and print out Breakpad-compatible symbol files. <br />
*** '''Why Rust?''' Doesn't rely on Microsoft closed-source libraries anymore, can be cross-compiled and run on a non-Windows host, is an order of magnitude faster, takes less than a third of the memory, produces better symbols and relies on an active and friendly upstream [https://github.com/getsentry/symbolic/ symbolic]<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/components various sync-related components used on iOS and Fenix], includes a cross-compiled FxA Rust client, and storage/syncing of bookmarks, history, logins, tabs and webextensions data.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1223934Oxidation2020-02-19T02:43:10Z<p>Nnethercote: /* Rust in Firefox */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more pleasant to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety.<br />
** Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
** The safety guarantees allow code that is designed more actively for performance, especially parallel performance.<br />
** The safety guarantees allow significant changes to existing code to be made quickly and with confidence.<br />
* Expressive and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A friendly and helpful community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating. (The new borrow checker released in Rust 1.31 helped greatly with this.)<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* The Rust Matrix channel contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central?<br /><br />
<br />
'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.<br />
<br />
<br />
'''Q:''' Do we support building standalone Rust programs?<br /><br />
<br />
'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.<br />
<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety provides protection against complexity.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
<br />
=== In progress ===<br />
<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend Project Visage] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* Replace the XML parser: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
<br />
=== Proposed ===<br />
<br />
* Parallel layout<br />
** '''Why Rust?''' Existing code from Servo, parallel performance.<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Image decoders?<br />
** '''Why Rust?''' Parsing untrusted input, some history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/fxa-rust-client fxa-rust-client], a cross-compiled FxA Rust client that can work with Firefox Sync keys and more.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1223933Oxidation2020-02-19T02:41:08Z<p>Nnethercote: /* Rust Weaknesses */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more pleasant to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety.<br />
** Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
** The safety guarantees allow code that is designed more actively for performance, especially parallel performance.<br />
** The safety guarantees allow significant changes to existing code to be made quickly and with confidence.<br />
* Expressive and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A friendly and helpful community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating. (The new borrow checker released in Rust 1.31 helped greatly with this.)<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* The #servo IRC channel contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central?<br /><br />
<br />
'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.<br />
<br />
<br />
'''Q:''' Do we support building standalone Rust programs?<br /><br />
<br />
'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.<br />
<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety provides protection against complexity.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
<br />
=== In progress ===<br />
<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend Project Visage] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* Replace the XML parser: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
<br />
=== Proposed ===<br />
<br />
* Parallel layout<br />
** '''Why Rust?''' Existing code from Servo, parallel performance.<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Image decoders?<br />
** '''Why Rust?''' Parsing untrusted input, some history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/fxa-rust-client fxa-rust-client], a cross-compiled FxA Rust client that can work with Firefox Sync keys and more.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1223932Oxidation2020-02-19T02:39:40Z<p>Nnethercote: /* Rust Strengths */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more pleasant to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety.<br />
** Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
** The safety guarantees allow code that is designed more actively for performance, especially parallel performance.<br />
** The safety guarantees allow significant changes to existing code to be made quickly and with confidence.<br />
* Expressive and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A friendly and helpful community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating.<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* The #servo IRC channel contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central?<br /><br />
<br />
'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.<br />
<br />
<br />
'''Q:''' Do we support building standalone Rust programs?<br /><br />
<br />
'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.<br />
<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety provides protection against complexity.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
<br />
=== In progress ===<br />
<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend Project Visage] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* Replace the XML parser: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
<br />
=== Proposed ===<br />
<br />
* Parallel layout<br />
** '''Why Rust?''' Existing code from Servo, parallel performance.<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Image decoders?<br />
** '''Why Rust?''' Parsing untrusted input, some history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/fxa-rust-client fxa-rust-client], a cross-compiled FxA Rust client that can work with Firefox Sync keys and more.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1223931Oxidation2020-02-19T02:39:27Z<p>Nnethercote: /* Rust Strengths */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more pleasant to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory-safety and thread-safety.<br />
** Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)<br />
** The safety guarantees allow code that is designed more actively for performance, especially parallel performance.<br />
** The safety guarantees allow significant changes to existing code to be made quickly and with confidence.<br />
* Expressive and pleasant to use, particularly once a moderate level of experience has been reached.<br />
* Excellent compiler error messages.<br />
* Excellent documentation.<br />
* A great community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating.<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* The #servo IRC channel contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central?<br /><br />
<br />
'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.<br />
<br />
<br />
'''Q:''' Do we support building standalone Rust programs?<br /><br />
<br />
'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.<br />
<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety provides protection against complexity.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
<br />
=== In progress ===<br />
<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend Project Visage] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* Replace the XML parser: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
<br />
=== Proposed ===<br />
<br />
* Parallel layout<br />
** '''Why Rust?''' Existing code from Servo, parallel performance.<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Image decoders?<br />
** '''Why Rust?''' Parsing untrusted input, some history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/fxa-rust-client fxa-rust-client], a cross-compiled FxA Rust client that can work with Firefox Sync keys and more.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1223930Oxidation2020-02-19T02:24:02Z<p>Nnethercote: /* Rust in Firefox */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more pleasant to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory safety, which prevents crashes and security vulnerabilities.<br />
* Thread safety, which enables improved performance via parallelism.<br />
* Nimbleness: the safety makes it easy to make significant changes quickly and with confidence.<br />
* Pleasant to use, particularly once a moderate level of experience has been reached.<br />
* A great community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating.<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* The #servo IRC channel contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:Gankra)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:nika)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central?<br /><br />
<br />
'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.<br />
<br />
<br />
'''Q:''' Do we support building standalone Rust programs?<br /><br />
<br />
'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.<br />
<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety provides protection against complexity.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Encoding detector: {{bug|1551276}} (shipped in Firefox 73)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
<br />
=== In progress ===<br />
<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend Project Visage] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
* Replace the XML parser: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
<br />
=== Proposed ===<br />
<br />
* Parallel layout<br />
** '''Why Rust?''' Existing code from Servo, parallel performance.<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Image decoders?<br />
** '''Why Rust?''' Parsing untrusted input, some history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/fxa-rust-client fxa-rust-client], a cross-compiled FxA Rust client that can work with Firefox Sync keys and more.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1223731Oxidation2020-02-12T21:26:30Z<p>Nnethercote: /* Proposed */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more pleasant to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory safety, which prevents crashes and security vulnerabilities.<br />
* Thread safety, which enables improved performance via parallelism.<br />
* Nimbleness: the safety makes it easy to make significant changes quickly and with confidence.<br />
* Pleasant to use, particularly once a moderate level of experience has been reached.<br />
* A great community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating.<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* The #servo IRC channel contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:gankro)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:mystor)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central?<br /><br />
<br />
'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.<br />
<br />
<br />
'''Q:''' Do we support building standalone Rust programs?<br /><br />
<br />
'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.<br />
<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety provides protection against complexity.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Encoding detector: {{bug|1551276}} (riding the Firefox 73 train)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
<br />
=== In progress ===<br />
<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend Project Visage] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
<br />
=== Proposed ===<br />
<br />
* Parallel layout<br />
** '''Why Rust?''' Existing code from Servo, parallel performance.<br />
* Replace the XML parser: {{bug|1611289}}<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Image decoders?<br />
** '''Why Rust?''' Parsing untrusted input, some history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/fxa-rust-client fxa-rust-client], a cross-compiled FxA Rust client that can work with Firefox Sync keys and more.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1222992Oxidation2020-01-31T04:11:33Z<p>Nnethercote: /* In progress */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more pleasant to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory safety, which prevents crashes and security vulnerabilities.<br />
* Thread safety, which enables improved performance via parallelism.<br />
* Nimbleness: the safety makes it easy to make significant changes quickly and with confidence.<br />
* Pleasant to use, particularly once a moderate level of experience has been reached.<br />
* A great community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating.<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* [https://gist.github.com/zbraniecki/b251714d77ffebbc73c03447f2b2c69f Crossing the C++/Rust boundary can be difficult].<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* The #servo IRC channel contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:gankro)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:mystor)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central?<br /><br />
<br />
'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.<br />
<br />
<br />
'''Q:''' Do we support building standalone Rust programs?<br /><br />
<br />
'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.<br />
<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety provides protection against complexity.<br />
* kvstore (key-value storage backed by LMDB): {{bug|1490496}} (shipped in Firefox 67)<br />
** '''Why Rust?''' The rkv crate provides a safe, ergonomic wrapper around LMDB, our choice for simple key-value storage in Firefox. kvstore wraps rkv in an asynchronous XPCOM API for JS and C++ callers.<br />
* XUL store, backed by rkv: {{bug|1460811}} (landed in Firefox 68, used in Nightly only)<br />
* TLS certificate store, backed by rkv: {{bug|1429796}} (shipped in Firefox 68)<br />
* Synced bookmark merger: {{bug|1482608}} (shipped in Firefox 68, on by default in Nightly and early Beta)<br />
** '''Why Rust?''' Code sharing! The bookmark merging algorithm was factored out into a [https://crates.io/crates/dogear separate crate], and is shared between Desktop and [https://github.com/mozilla/application-services all our mobile products].<br />
* Windows BITS interface: {{bug|1520321}} (shipped in Firefox 68)<br />
* Japanese encoding detector: {{bug|1543077}} (shipped in Firefox 69)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer.<br />
* Unicode Language Identifier: {{bug|1571915}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Much faster, parser-heavy, easier to handle low-memory footprint thanks to `tinystr`.<br />
* Language Negotiation: {{bug|1581960}} (shipped in Firefox 72)<br />
** '''Why Rust?''' Ties into `unic-langid`, easier to handle list filtering and ordering.<br />
* Encoding detector: {{bug|1551276}} (riding the Firefox 73 train)<br />
** '''Why Rust?''' Builds upon encoding_rs, has tiny FFI surface, subject matter prone to accesses past the bounds of a buffer, potentially parallelizable with Rayon.<br />
<br />
=== In progress ===<br />
<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* [https://github.com/mozilla-spidermonkey/rust-frontend Project Visage] A Rust front-end for SpiderMonkey (featuring [https://github.com/mozilla-spidermonkey/jsparagus jsparagus]).<br />
** '''Why Rust?''' Parses untrusted input. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
* Background Update Agent for Windows: {{bug|1343669}}<br />
<br />
=== Proposed ===<br />
<br />
* Parallel layout<br />
** '''Why Rust?''' Existing code from Servo, parallel performance.<br />
* Replace the XML parser<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Image decoders?<br />
** '''Why Rust?''' Parsing untrusted input, some history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/fxa-rust-client fxa-rust-client], a cross-compiled FxA Rust client that can work with Firefox Sync keys and more.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Platform/PrefsOverhaul&diff=1216122Platform/PrefsOverhaul2019-08-07T12:45:01Z<p>Nnethercote: /* {{mok|}} static-prefs */</p>
<hr />
<div>libpref has a lot of problems. The [https://docs.google.com/document/d/1V5Wc9bXwfgMG2JOsswvDPVwZl_xiaSBxwJXf3fiEaU8/ All About Prefs] document describes libpref in detail and covers a lot of the problems. Because prefs are used so widely, these problems affect many people and many parts of the codebase.<br />
<br />
In late 2017 and early 2018 nnethercote is overhauling libpref and fixing a lot of these problems. This page covers that work.<br />
<br />
= Major pieces =<br />
<br />
A lot of work has been done to generally clean up libpref's internals, e.g. see {{bug|1407526}}. This work is important, but this page will focus on larger changes, particularly those that affect how libpref is used.<br />
<br />
== {{mdone|}} <tt>clang-format</tt> ==<br />
<br />
* Use clang-format to reformat all libpref source files.<br />
* {{Bug|1405598}}, {{bug|1405908}}, {{bug|1405935}}<br />
<br />
Benefits<br />
* Improves readability.<br />
* Saves time going forward not having to make formatting decisions.<br />
<br />
== {{mdone|}} <tt>merge-files</tt> ==<br />
<br />
* Combine all libpref C++ source files into one .cpp and one .h file.<br />
* {{Bug|1407112}}<br />
<br />
Benefits<br />
* Allows unnecessary internal interfaces and indirection to be removed. (Lots of these have been done, tracked under {{bug|1407526}}.)<br />
<br />
== {{mdone|}} <tt>no-extension-prefs</tt> ==<br />
<br />
* Remove code supporting extension-specific prefs file, as supported by legacy extensions.<br />
* {{Bug|1413413}}<br />
<br />
Benefits<br />
* Less code.<br />
* Simpler libpref startup.<br />
<br />
== {{mdone|}} <tt>new-parser</tt> ==<br />
* Rewrite the prefs parser.<br />
* {{Bug|1423840}}, {{bug|107264}}<br />
* [https://blog.mozilla.org/nnethercote/2018/03/09/a-new-preferences-parser-for-firefox/ Blog post]<br />
<br />
Benefits<br />
* New parser is faster.<br />
* New parser is safer (because it's written in Rust).<br />
* New parser is more correct and better tested (the old one got various obscure edge cases wrong).<br />
* New parser is more maintainable, much easier to modify.<br />
* New parser has error recovery and better error messages.<br />
* New parser catches integer overflow.<br />
* Unblocks <tt>default-pref-attributes</tt>.<br />
<br />
Notes<br />
* New parser is slightly stricter, rejects some malformed input that the old parser accepted. Error recovery minimizes the risk of data loss, because malformed pref lines in prefs.js will be removed but well-formed pref lines afterwards are preserved.<br />
<br />
== {{mdone|}} <tt>less-IPC</tt> ==<br />
<br />
* Only send possibly-changed prefs to content processes when they start up.<br />
* {{bug|1436863}}<br />
* [https://blog.mozilla.org/nnethercote/2018/02/22/nicer-commands-for-content-processes/ Blog post]<br />
<br />
Benefits<br />
* Greatly reduces the amount of data the parent has to send to each new content process. On my Linux64 box:<br />
** Sent via the process command (early prefs): ~222 prefs --> ~3 prefs.<br />
** Sent via IPC (late prefs): ~3165 prefs --> ~180 prefs.<br />
* Makes content process commands smaller and nicer, fixing {{bug|1373157}}.<br />
* Avoids double initialization (hash table lookups) for all these prefs.<br />
* Unblocks <tt>no-early-late-split</tt>.<br />
<br />
== {{mdone|}} <tt>default-pref-attributes</tt> ==<br />
<br />
* Introduce a distinction between the grammar used for default pref files and user pref files, with the former being more powerful.<br />
* Add "pref attributes" (boolean flags) to default prefs.<br />
* <tt>sticky</tt> and <tt>locked</tt> are the first two attributes.<br />
* {{Bug|440908}}<br />
* [https://blog.mozilla.org/nnethercote/2018/03/09/a-new-preferences-parser-for-firefox/ Blog post] ("Attributes" section at the end)<br />
<br />
Benefits<br />
* Default prefs can now be locked in the data file (first requested 10 years ago).<br />
* Default/user grammar split means default user file format can evolve without affecting user files.<br />
* More info about each pref is in a single place; avoids the need for various blacklists/whitelists.<br />
* Additional attributes can be added in the future. Possibilities:<br />
** Not needed by content processes?<br />
** Show in about:support?<br />
** Show in about:config? (new)<br />
** Allow changing in about:config? (new)<br />
** Sync it?<br />
** Ignore in private browsing mode? (new)<br />
** Expire at some point in the future? (new)<br />
<br />
== {{mdone|}} <tt>no-prefs-in-commands</tt> ==<br />
<br />
* Don't embed prefs in content process commands; use shared memory instead.<br />
* {{Bug|1438678}}<br />
<br />
Benefits<br />
* The amount of data passable via shared memory is much higher than via commands.<br />
* Minimizes potential bloat in content process commands.<br />
* Unblocks <tt>no-early-late-split</tt>.<br />
<br />
== {{mdone|}} <tt>no-early-late-split</tt> ==<br />
<br />
* Pass all changed pref values (not just early prefs) to new content processes via shared memory.<br />
* {{Bug|1436911}}<br />
<br />
Benefits<br />
* Removes the need for the early prefs list (dom/ipc/ContentProcesses.{h,cpp}) and the associated checking, which is ugly and often trips people up (e.g. {{Bug|1432979}}, {{Bug|1439406}}).<br />
* Using prefnames instead of indices fixes some fragility (fixing {{bug|1419432}})<br />
* Fixes the problem of early prefs being installed as unlocked default values even if they are locked and/or have user values.<br />
* Unblocks <tt>static-prefs</tt>.<br />
<br />
== {{mok|}} <tt>static-prefs</tt> ==<br />
<br />
* Introduce a mechanism for prefs to be defined in the binary instead of a prefs data file.<br />
* Not all prefs will/should be defined in the binary, but for C++ only prefs this has some big advantages, esp. for VarCache prefs.<br />
* A lot of prefs can be converted, which will be a gradual process because there are so many of them.<br />
* {{Bug|1436655}} (mechanism), {{Bug|1448219}} (conversions)<br />
<br />
Benefits<br />
* Less code to define and setup each pref.<br />
* More info about these prefs is in a single place, rather than two or more places; avoids error-prone duplication of prefnames and default values.<br />
* Prevent direct modification of VarCache prefs, which leads to consistency problems (e.g. {{bug|1438433}}).<br />
* Use of getters to access VarCache prefs allows checking when accessing VarCache prefs.<br />
* Use of getters avoids possible mistyping of pref names.<br />
* <tt>MediaPrefs</tt> can be removed. (But not <tt>gfxPrefs</tt>, yet; that's a harder nut to crack.)<br />
** <tt>gfxPrefs</tt> was removed in {{Bug|1550422}}.<br />
* Initializing from binary should be faster than parsing a data file.<br />
* Static prefs are usable from Rust code.<br />
* Unblocks <tt>less-racy-VarCache-prefs</tt>.<br />
<br />
Downsides<br />
* Adding/removing/modifying one of these prefs causes a lot of recompilation.<br />
** {{Bug|1564724}} and {{Bug|1563139}} improved things by (a) generating the header file from a YAML file, and (b) splitting that generated header file into many smaller pieces, each one causing much less recompilation when changed.<br />
<br />
== {{mdone|}} <tt>less-racy-VarCache-prefs</tt> ==<br />
<br />
* Use of VarCache getters allows detection of multi-threaded VarCache prefs that should be atomic.<br />
* {{bug|1436916}}<br />
<br />
Benefits<br />
* Fewer races!</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Platform/PrefsOverhaul&diff=1216117Platform/PrefsOverhaul2019-08-06T23:51:02Z<p>Nnethercote: /* {{mok|}} static-prefs */</p>
<hr />
<div>libpref has a lot of problems. The [https://docs.google.com/document/d/1V5Wc9bXwfgMG2JOsswvDPVwZl_xiaSBxwJXf3fiEaU8/ All About Prefs] document describes libpref in detail and covers a lot of the problems. Because prefs are used so widely, these problems affect many people and many parts of the codebase.<br />
<br />
In late 2017 and early 2018 nnethercote is overhauling libpref and fixing a lot of these problems. This page covers that work.<br />
<br />
= Major pieces =<br />
<br />
A lot of work has been done to generally clean up libpref's internals, e.g. see {{bug|1407526}}. This work is important, but this page will focus on larger changes, particularly those that affect how libpref is used.<br />
<br />
== {{mdone|}} <tt>clang-format</tt> ==<br />
<br />
* Use clang-format to reformat all libpref source files.<br />
* {{Bug|1405598}}, {{bug|1405908}}, {{bug|1405935}}<br />
<br />
Benefits<br />
* Improves readability.<br />
* Saves time going forward not having to make formatting decisions.<br />
<br />
== {{mdone|}} <tt>merge-files</tt> ==<br />
<br />
* Combine all libpref C++ source files into one .cpp and one .h file.<br />
* {{Bug|1407112}}<br />
<br />
Benefits<br />
* Allows unnecessary internal interfaces and indirection to be removed. (Lots of these have been done, tracked under {{bug|1407526}}.)<br />
<br />
== {{mdone|}} <tt>no-extension-prefs</tt> ==<br />
<br />
* Remove code supporting extension-specific prefs file, as supported by legacy extensions.<br />
* {{Bug|1413413}}<br />
<br />
Benefits<br />
* Less code.<br />
* Simpler libpref startup.<br />
<br />
== {{mdone|}} <tt>new-parser</tt> ==<br />
* Rewrite the prefs parser.<br />
* {{Bug|1423840}}, {{bug|107264}}<br />
* [https://blog.mozilla.org/nnethercote/2018/03/09/a-new-preferences-parser-for-firefox/ Blog post]<br />
<br />
Benefits<br />
* New parser is faster.<br />
* New parser is safer (because it's written in Rust).<br />
* New parser is more correct and better tested (the old one got various obscure edge cases wrong).<br />
* New parser is more maintainable, much easier to modify.<br />
* New parser has error recovery and better error messages.<br />
* New parser catches integer overflow.<br />
* Unblocks <tt>default-pref-attributes</tt>.<br />
<br />
Notes<br />
* New parser is slightly stricter, rejects some malformed input that the old parser accepted. Error recovery minimizes the risk of data loss, because malformed pref lines in prefs.js will be removed but well-formed pref lines afterwards are preserved.<br />
<br />
== {{mdone|}} <tt>less-IPC</tt> ==<br />
<br />
* Only send possibly-changed prefs to content processes when they start up.<br />
* {{bug|1436863}}<br />
* [https://blog.mozilla.org/nnethercote/2018/02/22/nicer-commands-for-content-processes/ Blog post]<br />
<br />
Benefits<br />
* Greatly reduces the amount of data the parent has to send to each new content process. On my Linux64 box:<br />
** Sent via the process command (early prefs): ~222 prefs --> ~3 prefs.<br />
** Sent via IPC (late prefs): ~3165 prefs --> ~180 prefs.<br />
* Makes content process commands smaller and nicer, fixing {{bug|1373157}}.<br />
* Avoids double initialization (hash table lookups) for all these prefs.<br />
* Unblocks <tt>no-early-late-split</tt>.<br />
<br />
== {{mdone|}} <tt>default-pref-attributes</tt> ==<br />
<br />
* Introduce a distinction between the grammar used for default pref files and user pref files, with the former being more powerful.<br />
* Add "pref attributes" (boolean flags) to default prefs.<br />
* <tt>sticky</tt> and <tt>locked</tt> are the first two attributes.<br />
* {{Bug|440908}}<br />
* [https://blog.mozilla.org/nnethercote/2018/03/09/a-new-preferences-parser-for-firefox/ Blog post] ("Attributes" section at the end)<br />
<br />
Benefits<br />
* Default prefs can now be locked in the data file (first requested 10 years ago).<br />
* Default/user grammar split means default user file format can evolve without affecting user files.<br />
* More info about each pref is in a single place; avoids the need for various blacklists/whitelists.<br />
* Additional attributes can be added in the future. Possibilities:<br />
** Not needed by content processes?<br />
** Show in about:support?<br />
** Show in about:config? (new)<br />
** Allow changing in about:config? (new)<br />
** Sync it?<br />
** Ignore in private browsing mode? (new)<br />
** Expire at some point in the future? (new)<br />
<br />
== {{mdone|}} <tt>no-prefs-in-commands</tt> ==<br />
<br />
* Don't embed prefs in content process commands; use shared memory instead.<br />
* {{Bug|1438678}}<br />
<br />
Benefits<br />
* The amount of data passable via shared memory is much higher than via commands.<br />
* Minimizes potential bloat in content process commands.<br />
* Unblocks <tt>no-early-late-split</tt>.<br />
<br />
== {{mdone|}} <tt>no-early-late-split</tt> ==<br />
<br />
* Pass all changed pref values (not just early prefs) to new content processes via shared memory.<br />
* {{Bug|1436911}}<br />
<br />
Benefits<br />
* Removes the need for the early prefs list (dom/ipc/ContentProcesses.{h,cpp}) and the associated checking, which is ugly and often trips people up (e.g. {{Bug|1432979}}, {{Bug|1439406}}).<br />
* Using prefnames instead of indices fixes some fragility (fixing {{bug|1419432}})<br />
* Fixes the problem of early prefs being installed as unlocked default values even if they are locked and/or have user values.<br />
* Unblocks <tt>static-prefs</tt>.<br />
<br />
== {{mok|}} <tt>static-prefs</tt> ==<br />
<br />
* Introduce a mechanism for prefs to be defined in the binary instead of a prefs data file.<br />
* Not all prefs will/should be defined in the binary, but for C++ only prefs this has some big advantages, esp. for VarCache prefs.<br />
* A lot of prefs can be converted, which will be a gradual process because there are so many of them.<br />
* {{Bug|1436655}} (mechanism), {{Bug|1448219}} (conversions)<br />
<br />
Benefits<br />
* Less code to define and setup each pref.<br />
* More info about these prefs is in a single place, rather than two or more places; avoids error-prone duplication of prefnames and default values.<br />
* Prevent direct modification of VarCache prefs, which leads to consistency problems (e.g. {{bug|1438433}}).<br />
* Use of getters to access VarCache prefs allows checking when accessing VarCache prefs.<br />
* Use of getters avoids possible mistyping of pref names.<br />
* <tt>MediaPrefs</tt> can be removed. (But not <tt>gfxPrefs</tt>, yet; that's a harder nut to crack.)<br />
** <tt>gfxPrefs</tt> was removed in {{Bug|1550422}}.<br />
* Initializing from binary should be faster than parsing a data file.<br />
* Unblocks <tt>less-racy-VarCache-prefs</tt>.<br />
<br />
Downsides<br />
* Adding/removing/modifying one of these prefs causes a lot of recompilation.<br />
** {{Bug|1564724}} and {{Bug|1563139}} improved things by (a) generating the header file from a YAML file, and (b) splitting that generated header file into many smaller pieces, each one causing much less recompilation when changed.<br />
<br />
== {{mdone|}} <tt>less-racy-VarCache-prefs</tt> ==<br />
<br />
* Use of VarCache getters allows detection of multi-threaded VarCache prefs that should be atomic.<br />
* {{bug|1436916}}<br />
<br />
Benefits<br />
* Fewer races!</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Platform/PrefsOverhaul&diff=1215673Platform/PrefsOverhaul2019-07-29T23:14:37Z<p>Nnethercote: /* {{mok|}} static-prefs */</p>
<hr />
<div>libpref has a lot of problems. The [https://docs.google.com/document/d/1V5Wc9bXwfgMG2JOsswvDPVwZl_xiaSBxwJXf3fiEaU8/ All About Prefs] document describes libpref in detail and covers a lot of the problems. Because prefs are used so widely, these problems affect many people and many parts of the codebase.<br />
<br />
In late 2017 and early 2018 nnethercote is overhauling libpref and fixing a lot of these problems. This page covers that work.<br />
<br />
= Major pieces =<br />
<br />
A lot of work has been done to generally clean up libpref's internals, e.g. see {{bug|1407526}}. This work is important, but this page will focus on larger changes, particularly those that affect how libpref is used.<br />
<br />
== {{mdone|}} <tt>clang-format</tt> ==<br />
<br />
* Use clang-format to reformat all libpref source files.<br />
* {{Bug|1405598}}, {{bug|1405908}}, {{bug|1405935}}<br />
<br />
Benefits<br />
* Improves readability.<br />
* Saves time going forward not having to make formatting decisions.<br />
<br />
== {{mdone|}} <tt>merge-files</tt> ==<br />
<br />
* Combine all libpref C++ source files into one .cpp and one .h file.<br />
* {{Bug|1407112}}<br />
<br />
Benefits<br />
* Allows unnecessary internal interfaces and indirection to be removed. (Lots of these have been done, tracked under {{bug|1407526}}.)<br />
<br />
== {{mdone|}} <tt>no-extension-prefs</tt> ==<br />
<br />
* Remove code supporting extension-specific prefs file, as supported by legacy extensions.<br />
* {{Bug|1413413}}<br />
<br />
Benefits<br />
* Less code.<br />
* Simpler libpref startup.<br />
<br />
== {{mdone|}} <tt>new-parser</tt> ==<br />
* Rewrite the prefs parser.<br />
* {{Bug|1423840}}, {{bug|107264}}<br />
* [https://blog.mozilla.org/nnethercote/2018/03/09/a-new-preferences-parser-for-firefox/ Blog post]<br />
<br />
Benefits<br />
* New parser is faster.<br />
* New parser is safer (because it's written in Rust).<br />
* New parser is more correct and better tested (the old one got various obscure edge cases wrong).<br />
* New parser is more maintainable, much easier to modify.<br />
* New parser has error recovery and better error messages.<br />
* New parser catches integer overflow.<br />
* Unblocks <tt>default-pref-attributes</tt>.<br />
<br />
Notes<br />
* New parser is slightly stricter, rejects some malformed input that the old parser accepted. Error recovery minimizes the risk of data loss, because malformed pref lines in prefs.js will be removed but well-formed pref lines afterwards are preserved.<br />
<br />
== {{mdone|}} <tt>less-IPC</tt> ==<br />
<br />
* Only send possibly-changed prefs to content processes when they start up.<br />
* {{bug|1436863}}<br />
* [https://blog.mozilla.org/nnethercote/2018/02/22/nicer-commands-for-content-processes/ Blog post]<br />
<br />
Benefits<br />
* Greatly reduces the amount of data the parent has to send to each new content process. On my Linux64 box:<br />
** Sent via the process command (early prefs): ~222 prefs --> ~3 prefs.<br />
** Sent via IPC (late prefs): ~3165 prefs --> ~180 prefs.<br />
* Makes content process commands smaller and nicer, fixing {{bug|1373157}}.<br />
* Avoids double initialization (hash table lookups) for all these prefs.<br />
* Unblocks <tt>no-early-late-split</tt>.<br />
<br />
== {{mdone|}} <tt>default-pref-attributes</tt> ==<br />
<br />
* Introduce a distinction between the grammar used for default pref files and user pref files, with the former being more powerful.<br />
* Add "pref attributes" (boolean flags) to default prefs.<br />
* <tt>sticky</tt> and <tt>locked</tt> are the first two attributes.<br />
* {{Bug|440908}}<br />
* [https://blog.mozilla.org/nnethercote/2018/03/09/a-new-preferences-parser-for-firefox/ Blog post] ("Attributes" section at the end)<br />
<br />
Benefits<br />
* Default prefs can now be locked in the data file (first requested 10 years ago).<br />
* Default/user grammar split means default user file format can evolve without affecting user files.<br />
* More info about each pref is in a single place; avoids the need for various blacklists/whitelists.<br />
* Additional attributes can be added in the future. Possibilities:<br />
** Not needed by content processes?<br />
** Show in about:support?<br />
** Show in about:config? (new)<br />
** Allow changing in about:config? (new)<br />
** Sync it?<br />
** Ignore in private browsing mode? (new)<br />
** Expire at some point in the future? (new)<br />
<br />
== {{mdone|}} <tt>no-prefs-in-commands</tt> ==<br />
<br />
* Don't embed prefs in content process commands; use shared memory instead.<br />
* {{Bug|1438678}}<br />
<br />
Benefits<br />
* The amount of data passable via shared memory is much higher than via commands.<br />
* Minimizes potential bloat in content process commands.<br />
* Unblocks <tt>no-early-late-split</tt>.<br />
<br />
== {{mdone|}} <tt>no-early-late-split</tt> ==<br />
<br />
* Pass all changed pref values (not just early prefs) to new content processes via shared memory.<br />
* {{Bug|1436911}}<br />
<br />
Benefits<br />
* Removes the need for the early prefs list (dom/ipc/ContentProcesses.{h,cpp}) and the associated checking, which is ugly and often trips people up (e.g. {{Bug|1432979}}, {{Bug|1439406}}).<br />
* Using prefnames instead of indices fixes some fragility (fixing {{bug|1419432}})<br />
* Fixes the problem of early prefs being installed as unlocked default values even if they are locked and/or have user values.<br />
* Unblocks <tt>static-prefs</tt>.<br />
<br />
== {{mok|}} <tt>static-prefs</tt> ==<br />
<br />
* Introduce a mechanism for prefs to be defined in the binary instead of a prefs data file.<br />
* Not all prefs will/should be defined in the binary, but for C++ only prefs this has some big advantages, esp. for VarCache prefs.<br />
* A lot of prefs can be converted, which will be a gradual process because there are so many of them.<br />
* {{Bug|1436655}} (mechanism), {{Bug|1448219}} (conversions)<br />
<br />
Benefits<br />
* More info about these prefs is in a single place, rather than two or more places; avoids error-prone duplication of prefnames and default values.<br />
* Prevent direct modification of VarCache prefs, which leads to consistency problems (e.g. {{bug|1438433}}).<br />
* Use of getters to access VarCache prefs allows checking when accessing VarCache prefs.<br />
* Use of getters avoids possible mistyping of pref names.<br />
* <tt>MediaPrefs</tt> can be removed. (But not <tt>gfxPrefs</tt>, yet; that's a harder nut to crack.)<br />
** <tt>gfxPrefs</tt> was removed in {{Bug|1550422}}.<br />
* Initializing from binary should be faster than parsing a data file.<br />
* Unblocks <tt>less-racy-VarCache-prefs</tt>.<br />
<br />
Downsides<br />
* Adding/removing/modifying one of these prefs causes a lot of recompilation.<br />
** {{Bug|1564724}} and {{Bug|1563139}} improved things by (a) generating the header file from a YAML file, and (b) splitting that generated header file into many smaller pieces, each one causing much less recompilation when changed.<br />
<br />
== {{mdone|}} <tt>less-racy-VarCache-prefs</tt> ==<br />
<br />
* Use of VarCache getters allows detection of multi-threaded VarCache prefs that should be atomic.<br />
* {{bug|1436916}}<br />
<br />
Benefits<br />
* Fewer races!</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1213996Oxidation2019-06-19T23:42:03Z<p>Nnethercote: /* In progress */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more pleasant to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory safety, which prevents crashes and security vulnerabilities.<br />
* Thread safety, which enables improved performance via parallelism.<br />
* Nimbleness: the safety makes it easy to make significant changes quickly and with confidence.<br />
* Pleasant to use, particularly once a moderate level of experience has been reached.<br />
* A great community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating.<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* Crossing the C++/Rust boundary can be difficult.<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* The #servo IRC channel contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:gankro)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:mystor)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central?<br /><br />
<br />
'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.<br />
<br />
<br />
'''Q:''' Do we support building standalone Rust programs?<br /><br />
<br />
'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.<br />
<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety provides protection against complexity.<br />
<br />
=== In progress ===<br />
<br />
* Integrate [https://github.com/projectfluent/fluent-rs fluent-rs], a localization system: {{bug|1560038}}<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
<br />
=== Proposed ===<br />
<br />
* Parallel layout<br />
** '''Why Rust?''' Existing code from Servo, parallel performance.<br />
* Replace the XML parser<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Image decoders?<br />
** '''Why Rust?''' Parsing untrusted input, some history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/fxa-rust-client fxa-rust-client], a cross-compiled FxA Rust client that can work with Firefox Sync keys and more.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1213995Oxidation2019-06-19T21:04:45Z<p>Nnethercote: /* Blockers and obstacles */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more pleasant to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory safety, which prevents crashes and security vulnerabilities.<br />
* Thread safety, which enables improved performance via parallelism.<br />
* Nimbleness: the safety makes it easy to make significant changes quickly and with confidence.<br />
* Pleasant to use, particularly once a moderate level of experience has been reached.<br />
* A great community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating.<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* Crossing the C++/Rust boundary can be difficult.<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* The #servo IRC channel contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:gankro)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:mystor)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central?<br /><br />
<br />
'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.<br />
<br />
<br />
'''Q:''' Do we support building standalone Rust programs?<br /><br />
<br />
'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.<br />
<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety provides protection against complexity.<br />
<br />
=== In progress ===<br />
<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
<br />
=== Proposed ===<br />
<br />
* Parallel layout<br />
** '''Why Rust?''' Existing code from Servo, parallel performance.<br />
* Replace the XML parser<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Image decoders?<br />
** '''Why Rust?''' Parsing untrusted input, some history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/fxa-rust-client fxa-rust-client], a cross-compiled FxA Rust client that can work with Firefox Sync keys and more.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1213994Oxidation2019-06-19T21:03:32Z<p>Nnethercote: /* Proposed */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more pleasant to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory safety, which prevents crashes and security vulnerabilities.<br />
* Thread safety, which enables improved performance via parallelism.<br />
* Nimbleness: the safety makes it easy to make significant changes quickly and with confidence.<br />
* Pleasant to use, particularly once a moderate level of experience has been reached.<br />
* A great community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating.<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* Crossing the C++/Rust boundary can be difficult.<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* The #servo IRC channel contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:gankro)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:mystor)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central?<br /><br />
<br />
'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.<br />
<br />
<br />
'''Q:''' Do we support building standalone Rust programs?<br /><br />
<br />
'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.<br />
<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety provides protection against complexity.<br />
<br />
=== In progress ===<br />
<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
<br />
=== Proposed ===<br />
<br />
* Parallel layout<br />
** '''Why Rust?''' Existing code from Servo, parallel performance.<br />
* Replace the XML parser<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Image decoders?<br />
** '''Why Rust?''' Parsing untrusted input, some history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
* Crash reporter<br />
** '''Why Rust?''' Code needs rewriting, useful Rust crates exist that could be used.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/fxa-rust-client fxa-rust-client], a cross-compiled FxA Rust client that can work with Firefox Sync keys and more.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Inlining between C++ and Rust would reduce cost of crossing the language barrier<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1213993Oxidation2019-06-19T20:55:51Z<p>Nnethercote: /* Documentation and assistance */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more pleasant to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory safety, which prevents crashes and security vulnerabilities.<br />
* Thread safety, which enables improved performance via parallelism.<br />
* Nimbleness: the safety makes it easy to make significant changes quickly and with confidence.<br />
* Pleasant to use, particularly once a moderate level of experience has been reached.<br />
* A great community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating.<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* Crossing the C++/Rust boundary can be difficult.<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* The #servo IRC channel contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:gankro)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:mystor)<br />
** Cameron McCormack (:heycam)<br />
<br />
== FAQ ==<br />
<br />
'''Q:''' What is the policy for vendoring non-Mozilla crates into mozilla-central?<br /><br />
<br />
'''A:''' It is possible. The most important point is that the license must be compatible. Reviewers should also look at the crate code some to check that it looks reasonable (especially for unsafe code) and that it has reasonable tests. Other than that, there is no formal sign-off procedure, but one may be added in the future.<br />
<br />
<br />
'''Q:''' Do we support building standalone Rust programs?<br /><br />
<br />
'''A:''' Yes! Look for <tt>RUST_PROGRAMS</tt> rules in <tt>moz.build</tt> files.<br />
<br />
<br />
'''Q:''' How are in-tree Rust crates tested?<br /><br />
<br />
'''A:''' In general we don't run tests for third-party crates; the assumption is that these crates are sufficiently well-tested elsewhere. (Which means that large test fixtures should be removed when vendoring third-party crates, because they just bloat mozilla-central.) Mozilla crates can be tested with <tt>cargo test</tt> by adding them to <tt>RUST_TESTS</tt> in <tt>toolkit/library/rust/moz.build</tt>. Alternatively, you can write a GTest that uses FFI to call into Rust code.<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety provides protection against complexity.<br />
<br />
=== In progress ===<br />
<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
<br />
=== Proposed ===<br />
<br />
* Parallel layout<br />
** '''Why Rust?''' Existing code from Servo, parallel performance.<br />
* Replace the XML parser<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Image decoders?<br />
** '''Why Rust?''' Parsing untrusted input, some history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/fxa-rust-client fxa-rust-client], a cross-compiled FxA Rust client that can work with Firefox Sync keys and more.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Inlining between C++ and Rust would reduce cost of crossing the language barrier<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1213992Oxidation2019-06-19T20:29:39Z<p>Nnethercote: /* In progress */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more pleasant to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory safety, which prevents crashes and security vulnerabilities.<br />
* Thread safety, which enables improved performance via parallelism.<br />
* Nimbleness: the safety makes it easy to make significant changes quickly and with confidence.<br />
* Pleasant to use, particularly once a moderate level of experience has been reached.<br />
* A great community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating.<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* Crossing the C++/Rust boundary can be difficult.<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* The #servo IRC channel contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:gankro)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:mystor)<br />
** Cameron McCormack (:heycam)<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety provides protection against complexity.<br />
<br />
=== In progress ===<br />
<br />
* [https://github.com/mozilla/neqo neqo] A QUIC implentation.<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
<br />
=== Proposed ===<br />
<br />
* Parallel layout<br />
** '''Why Rust?''' Existing code from Servo, parallel performance.<br />
* Replace the XML parser<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Image decoders?<br />
** '''Why Rust?''' Parsing untrusted input, some history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/fxa-rust-client fxa-rust-client], a cross-compiled FxA Rust client that can work with Firefox Sync keys and more.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Inlining between C++ and Rust would reduce cost of crossing the language barrier<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1213991Oxidation2019-06-19T20:26:36Z<p>Nnethercote: /* Rust in Firefox */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more pleasant to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory safety, which prevents crashes and security vulnerabilities.<br />
* Thread safety, which enables improved performance via parallelism.<br />
* Nimbleness: the safety makes it easy to make significant changes quickly and with confidence.<br />
* Pleasant to use, particularly once a moderate level of experience has been reached.<br />
* A great community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating.<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* Crossing the C++/Rust boundary can be difficult.<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* [https://docs.google.com/presentation/d/1qkPwISU1BvsTVyqLuVhisSMuIS_DiXb8X09-boszcu0/edit#slide=id.g5bfdbbe5c9_0_71 How to build an XPCOM component in Rust]<br />
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/u8scZop3FkM In-tree helper crates for Rust XPCOM components]<br />
* The #servo IRC channel contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:gankro)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:mystor)<br />
** Cameron McCormack (:heycam)<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety provides protection against complexity.<br />
<br />
=== In progress ===<br />
<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
<br />
=== Proposed ===<br />
<br />
* Parallel layout<br />
** '''Why Rust?''' Existing code from Servo, parallel performance.<br />
* Replace the XML parser<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Image decoders?<br />
** '''Why Rust?''' Parsing untrusted input, some history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/fxa-rust-client fxa-rust-client], a cross-compiled FxA Rust client that can work with Firefox Sync keys and more.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Inlining between C++ and Rust would reduce cost of crossing the language barrier<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1213990Oxidation2019-06-19T20:20:35Z<p>Nnethercote: /* Blockers and obstacles */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more pleasant to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory safety, which prevents crashes and security vulnerabilities.<br />
* Thread safety, which enables improved performance via parallelism.<br />
* Nimbleness: the safety makes it easy to make significant changes quickly and with confidence.<br />
* Pleasant to use, particularly once a moderate level of experience has been reached.<br />
* A great community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating.<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* Crossing the C++/Rust boundary can be difficult.<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* The #servo IRC channel contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:gankro)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:mystor)<br />
** Cameron McCormack (:heycam)<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety provides protection against complexity.<br />
<br />
=== In progress ===<br />
<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
<br />
=== Proposed ===<br />
<br />
* Parallel layout<br />
** '''Why Rust?''' Existing code from Servo, parallel performance.<br />
* Replace the XML parser<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Image decoders?<br />
** '''Why Rust?''' Parsing untrusted input, some history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/fxa-rust-client fxa-rust-client], a cross-compiled FxA Rust client that can work with Firefox Sync keys and more.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Inlining between C++ and Rust would reduce cost of crossing the language barrier<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
<br />
= Meetings =<br />
<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercotehttps://wiki.mozilla.org/index.php?title=Oxidation&diff=1213989Oxidation2019-06-19T18:24:34Z<p>Nnethercote: /* Meetings */</p>
<hr />
<div>'''Oxidation''' is a project to integrate [https://www.rust-lang.org/ Rust] code in and around Firefox. <br />
<br />
Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more pleasant to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.<br />
<br />
This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.<br />
<br />
= Guidelines =<br />
<br />
The goal of this section is to provide some high-level guidelines about when Rust should be used. <br />
<br />
In summary, Rust should be used in the following situations.<br />
* For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.<br />
* For existing components it's more complicated!<br />
<br />
The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.<br />
<br />
== Rust Strengths ==<br />
<br />
Rust has the following strengths.<br />
* Memory safety, which prevents crashes and security vulnerabilities.<br />
* Thread safety, which enables improved performance via parallelism.<br />
* Nimbleness: the safety makes it easy to make significant changes quickly and with confidence.<br />
* Pleasant to use, particularly once a moderate level of experience has been reached.<br />
* A great community.<br />
<br />
== Rust Weaknesses ==<br />
<br />
One major issue with Rust relates to personnel.<br />
* There is a wide variety of experience levels within Mozilla, for both coding and reviewing.<br />
* Rust's learning curve is steep at the start, which can be intimidating.<br />
<br />
There are also technical challenges.<br />
* Compilation is slow.<br />
* Crossing the C++/Rust boundary can be difficult.<br />
<br />
See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.<br />
<br />
== Recommendations ==<br />
<br />
Therefore, Rust is most suitable in the following situations.<br />
* For components that are relatively standalone, with small and simple APIs.<br />
** This minimizes the C++/Rust boundary layer issues.<br />
** Infrastructure tools that are standalone programs are ideal.<br />
** Note that it's good software engineering practice to write loosely-coupled components anyway.<br />
* For components that process untrusted input, e.g. parsers.<br />
** Rust's memory safety is a big help here.<br />
** See the [http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf "Writing parsers like it is 2017"] paper for lots of good details.<br />
* For components where parallelism can provide big performance wins.<br />
* For components where Servo has demonstrated success.<br />
<br />
In terms of where to keep Rust crates, there are three options.<br />
* Put the crate in mozilla-central or in Servo's repository.<br />
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.<br />
* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.<br />
** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.<br />
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.<br />
** This makes sense for pre-existing third-party crates that we choose to import.<br />
** Otherwise, this option is not recommended, because vendoring is something of a hassle.<br />
<br />
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.<br />
<br />
= Documentation and assistance =<br />
<br />
== Rust in general ==<br />
<br />
* The [https://www.rust-lang.org/learn Rust Documentation] page is the best place to start. In particular, the [https://doc.rust-lang.org/book/ The Rust Programming Language] provides a good overview.<br />
* [https://www.rust-lang.org/en-US/community.html The Rust Community] page lists IRC channels, forums, and other places where Rust assistance can be obtained.<br />
* [http://shop.oreilly.com/product/0636920040385.do Programming Rust: Fast, Safe Systems Development], by Jim Blandy & Jason Orendorff, is a detailed guide to the language.<br />
* [https://github.com/ctjhoa/rust-learning rust-learning] is a huge collection of assorted Rust resources.<br />
<br />
== Rust in Firefox ==<br />
<br />
* [https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code Developer Documentation]<br />
* [https://firefox-source-docs.mozilla.org/build/buildsystem/rust.html Build System Documentation]<br />
* [[Rust_Update_Policy_for_Firefox|Rust Update Policy for Firefox]]<br />
* The #servo IRC channel contains lots of people who know about both Rust and Gecko.<br />
* Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view.<br />
** Alexis Beingessner (:gankro)<br />
** Josh Bowman-Matthews (:jdm)<br />
** Emilio Cobos Alvarez (:emilio)<br />
** Manish Goregaokar (:manishearth)<br />
** Nika Layzell (:mystor)<br />
** Cameron McCormack (:heycam)<br />
<br />
= Rust Components =<br />
<br />
== Within Firefox ==<br />
<br />
=== Shipped ===<br />
<br />
* MP4 metadata parser: {{bug|1161350}} (shipped for desktop in Firefox 48)<br />
** '''Why Rust?''' Parses untrusted input, replaces libstagefright, a 3rd-party library with a history of security vulnerabilities.<br />
* Replace uconv with encoding-rs: {{bug|1261841}} (shipped in Firefox 56)<br />
* CSS style calculation (from Servo): {{bug|stylo}} (shipped for desktop in Firefox 57)<br />
** '''Why Rust?''' Code taken from Servo, uses parallel algorithms.<br />
* U2F HID backend: {{bug|1388843}} (shipped in Firefox 57)<br />
* XPIDL binding generator ({{bug|1293362}}) (shipped in Firefox 60)<br />
* New prefs parser: {{bug|1423840}} (shipped in Firefox 60)<br />
** '''Why Rust?''' Old parser needed replacing. Well-separated component, simple interface, parses untrusted input.<br />
* Audio remoting for Linux: {{bug|1434156}} (shipped in Firefox 60)<br />
* WebRender: {{bug|webrender}} (shipped in Firefox 67, enabled for users with appropriate hardware)<br />
** '''Why Rust?''' Code taken from Servo, has high performance; Rust's memory and thread safety provides protection against complexity.<br />
<br />
=== In progress ===<br />
<br />
* [https://github.com/CraneStation/cranelift/ cranelift, a low-level retargetable code generator]: {{bug|1469027}}<br />
** '''Why Rust?''' It's a new, well-separated component with a clear interface. Also, Rust is a great language for writing compilers, due to algebraic data types and pattern matching.<br />
* Audio remoting for Windows: {{bug|1432303}}<br />
* Audio remoting for Mac OS: {{bug|1425788}}<br />
* SDP parsing in WebRTC: {{bug|1365792}}<br />
** '''Why Rust?''' SDP is a complex text protocol and the existing parser in C has a history of security issues.<br />
* Linebreaking with xi-unicode: {{bug|1290022}} (last update late 2016)<br />
<br />
=== Proposed ===<br />
<br />
* Parallel layout<br />
** '''Why Rust?''' Existing code from Servo, parallel performance.<br />
* Replace the XML parser<br />
** '''Why Rust?''' Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.<br />
* WebMIDI: {{bug|1201593}}, {{bug|1201596}}, {{bug|1201598}}<br />
* Gamepad code: {{bug|1286699}}<br />
* Replace the telemetry module(?)<br />
** '''Why Rust?''' The existing C++ code has a history of threading problems.<br />
* Replace DOM serializers (XML, HTML for Save As.., plain text)<br />
** '''Why Rust?''' Need a rewrite anyway. Minor history of security vulnerabilities.<br />
* Image decoders?<br />
** '''Why Rust?''' Parsing untrusted input, some history of security vulnerabilities.<br />
* Expose Rust API to JS Debugger: {{bug|1263317}}<br />
* Generate Rust bindings for IPDL actors ({{bug|1379739}})<br />
* WebM demuxer: {{bug|1267492}}<br />
* Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet)<br />
** '''Why Rust?''' Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
== Outside Firefox ==<br />
<br />
=== Completed ===<br />
<br />
* Testing<br />
** GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: {{bug|1340637}} ([https://github.com/mozilla/geckodriver/releases standalone releases])<br />
** [https://github.com/mozilla/grcov grcov], a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.<br />
* Build system, etc.<br />
** [https://github.com/mozilla/sccache/ sccache], compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI.<br />
** Parts of [https://github.com/mozsearch/mozsearch mozsearch], the backend for the [http://searchfox.org Searchfox] code indexing tool.<br />
** [https://github.com/luser/rust-makecab makecab], a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI.<br />
* Application Services, server-side<br />
** [https://github.com/mozilla-services/autopush-rs autopush-rs] Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols.<br />
*** '''Why Rust?''' Concise code with the memory efficiency of C.<br />
** [https://github.com/mozilla-services/megaphone/ Megaphone], a real-time update broadcast server for Firefox.<br />
** [https://github.com/mozilla/fxa-email-service/ fxa_email_service], a service for sending email to Firefox Accounts.<br />
** [https://github.com/mozilla-services/pairsona/ pairsona], a tool to associate instances of firefox.<br />
* Application Services, client-side<br />
** [https://github.com/mozilla/application-services/tree/master/fxa-rust-client fxa-rust-client], a cross-compiled FxA Rust client that can work with Firefox Sync keys and more.<br />
<br />
=== In Progress ===<br />
<br />
* IPDL Parser: {{bug|1316754}}<br />
** '''Why Rust?''' Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.<br />
<br />
= Blockers and obstacles =<br />
<br />
This section lists areas where Rust integration could be improved.<br />
* Tracking bug: Make the developer experience for Firefox + Rust great: {{Bug|rust-great}}<br />
* Compile speed and memory usage<br />
** Incremental compilation ([https://github.com/rust-lang/rust/labels/A-incr-comp A-incr-comp issues], [https://github.com/rust-lang/rust/labels/WG-compiler-incr WG-compiler-incr issues])<br />
** [https://users.rust-lang.org/t/contract-opportunity-mozilla-distributed-compilation-cache-written-in-rust/13898 Distributed compilation cache]<br />
** [https://github.com/rust-lang/cargo/issues/1997 Artifact caching]?<br />
* Inlining between C++ and Rust would reduce cost of crossing the language barrier<br />
* Debugging: improve gdb and lldb support for Rust. The first step is to establish Rust language support in DWARF distinct from the existing C++ support.<br />
* Bindings/interop<br />
** Immature rust-bindgen and cbindgen tools for general cross-language support. Working aroudn clang bugs in different versions and on different platforms can be tricky.<br />
** No IPDL binding generator ({{bug|1379739}})<br />
** No WebIDL binding generator for DOM components (Servo must have something here?)<br />
* Remaining minor crash report issues {{bug|1348896}}<br />
* IDE/symbol lookup support?<br />
* Code coverage?<br />
* Profiling improvements? Especially for parallel code<br />
* Test integration?<br />
* Are Rust's Vec, HashSet/HashMap as performant as Gecko's equivalents? {{bug|1425770}}<br />
<br />
= Meetings =<br />
<br />
* [https://github.com/servo/servo/wiki/Whistler-Oxidation-2019 Whistler, Jun 2019]<br />
* [https://github.com/servo/servo/wiki/Orlando-Oxidation-2018 Orlando, Dec 2018]<br />
* [https://github.com/servo/servo/wiki/San-Francisco-Oxidation San Francisco, Jun 2018]<br />
* [https://github.com/servo/servo/wiki/Austin-Oxidation Austin, Dec 2017]<br />
* [https://github.com/servo/servo/wiki/Mozlando-Oxidation Mozlando, Dec 2015]<br />
* [https://github.com/servo/servo/wiki/Oxidation-2015-11-05 Oxidation, Nov 2015]<br />
* [https://github.com/servo/servo/wiki/Whistler-GFX#servo-in-gecko Whistler, June 2015]<br />
* [https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko Mozlandia, Dec 2014]</div>Nnethercote