We would like to switch to using cross-language LTO on all of our
platforms, and we need to use a beta version of Rust on Mac to do that.
Differential Revision: https://phabricator.services.mozilla.com/D33316
--HG--
extra : moz-landing-system : lando
COFF-flavored lld collects timing stats about various phases of linking. This might be useful to have in logs. I left it off in developer builds to avoid spamming tight edit-compile cycles.
Differential Revision: https://phabricator.services.mozilla.com/D33319
--HG--
extra : moz-landing-system : lando
We cannot compile with just feature(gecko + debug_assertions), since that's how
debug rusttests get compiled and they don't have the refcount logging stuff.
We were getting away with it for the pre-existing usage of the style crate,
because it wasn't used during any test and presumably the linker didn't
complain. But servo_arc is definitely used in tests.
Differential Revision: https://phabricator.services.mozilla.com/D32691
We're planning on switching to IR-based profiling, so we can't use the
frontend-based instrumentation to collect the order in which functions
are executed...at least not during the build itself. Performance tests
indicate that not having the order information decreases performance
significantly. So we're going to check in static files for Win32 and
Win64 and use those to perform the ordering. It's OK if these files are
slightly out of date; as of this writing, builds that generate and then
use these files complain that ~1/3 of the functions can't be found (!).
We're just trying to do something slightly smarter than whatever the
linker default is.
Differential Revision: https://phabricator.services.mozilla.com/D31132
--HG--
extra : moz-landing-system : lando
This replaces the in-tree u2fhid (which has been renamed to
authenticator) by the published crate.
Differential Revision: https://phabricator.services.mozilla.com/D32221
--HG--
extra : moz-landing-system : lando
We can't yet enable the build by default since it pulls in networking functions
into libgkrust which runs afoul of the checks added in bug 1376621.
Differential Revision: https://phabricator.services.mozilla.com/D28353
--HG--
extra : moz-landing-system : lando
Configure the lmdb-rkv-sys Rust crate to use a smaller MDB_IDL_LOGN size in order to reduce allocations when opening an LMDB environment in read-write mode.
@glandium I adopted the configuration strategy you suggested of creating a "feature" for each reasonable value for the MDB_IDL_LOGN macro. Fortunately, the range of reasonable values is fairly small.
@nanj Based on your evalution in https://github.com/mozilla/lmdb/pull/2, a value of "9" for this macro should aggressively reduce the allocations while still supporting our existing use cases. But I'm open to increasing it, if you think a higher initial value would be preferable.
Differential Revision: https://phabricator.services.mozilla.com/D27559
--HG--
extra : moz-landing-system : lando
Before bug 938437, we had a rather large and error-prone
nsStaticXULComponents.cpp used to register all modules. That was
replaced with clever use of the linker, which allowed to avoid the mess
that maintaining that file was.
Fast forward to now, where after bug 1524687 and other work that
preceded it, we have a much smaller number of remaining static xpcom
components, registered via this linker hack, and don't expect to add
any new ones. The list should eventually go down to zero.
Within that context, it seems to be the right time to get rid of the
magic, and with it the problems it causes on its own.
Some of those components could probably be trivially be converted to
static registration via .conf files, but I didn't want to deal with the
possible need to increase the number of dummy modules in XPCOMInit.cpp.
They can still be converted as a followup.
Differential Revision: https://phabricator.services.mozilla.com/D26076
--HG--
extra : moz-landing-system : lando
This patch contains three fixes.
1) As in Bug 1515982, we use the constant for RT_MANIFEST instead of
the define, which needs winuser.rh to be included
2) We stop exempting the mingw builds from RCINCLUDE in
toolkit/library/moz.build which causes us to miss all of the
resources in xul.dll
3) We explicitly include IA2Marshal.dll instead of relying on
compiler magic to include it for us.
Differential Revision: https://phabricator.services.mozilla.com/D26295
--HG--
extra : moz-landing-system : lando
This is needed for cross-language LTO (bug 1512723). We don't want to block on waiting for 1.34's release, so we'll get a head start now, but we'll update to the final 1.34 release when available. Rust Forge estimates the release at 11 April.
Differential Revision: https://phabricator.services.mozilla.com/D25851
--HG--
extra : moz-landing-system : lando
This commit introduces a Rust XPCOM component,
`mozISyncedBookmarksMerger`, that wraps the Dogear crate for
merging and applying synced bookmarks.
How this works: `SyncedBookmarksMirror.jsm` manages opening
the connection, initializing the schema, and writing incoming
items into the mirror database. The new `mozISyncedBookmarksMerger`
holds a handle to the same connection. When JS code calls
`mozISyncedBookmarksMerger::apply`, the merger builds local and
remote trees, produces a merged tree, applies the tree back to Places,
and stages outgoing items for upload in a temp table, all on the
storage thread. It then calls back in to JS, which inflates Sync
records for outgoing items, notifies Places observers, and cleans up.
Since Dogear has a more robust merging algorithm that attempts to fix
up invalid trees, `test_bookmark_corruption.js` intentionally fails.
This is fixed in the next commit, which changes the merger to handle
invalid structure.
Differential Revision: https://phabricator.services.mozilla.com/D20076
--HG--
extra : moz-landing-system : lando
This commit wraps just enough of the mozStorage API to support the
bookmarks mirror. It's not complete: for example, there's no way
to open, clone, or close a connection, because the mirror handles
that from JS. The wrapper also omits shutdown blocking and retrying on
`SQLITE_BUSY`.
This commit also changes the behavior of sync and async mozStorage
connections. Async (`mozIStorageAsyncConnection`) methods may be called
from any thread on any connection. Sync (`mozIStorageConnection`)
methods may be called from any thread on a sync connection, and from
background threads on an async connection. All connections now QI
to `mozIStorageConnection`, but attempting to call a sync method on
an async connection from the main thread throws.
Finally, this commit exposes an `OpenedConnection::unsafeRawConnection`
getter in Sqlite.jsm, for JS code to access the underlying connection.
Differential Revision: https://phabricator.services.mozilla.com/D20073
--HG--
extra : moz-landing-system : lando
Emilio Cobos Álvarez
Chun-Min Chang
Sylvestre Ledru
Andreea Pavel
Chris Manchester
Kartikaya Gupta
shindli
Paul Adenot
Mike Hommey
Cosmin Sabou
Henri Sivonen
Nathan Froyd
David Major
Mihai Alexandru Michis
Bastien Orivel
Cameron McCormack
Myk Melez
Coroiu Cristina
Razvan Maries
Aaron Klotz
Ryan VanderMeulen
Tom Ritter
Masatoshi Kimura
Lina Cambridge
Adam Gashlin
Mark Goodwin