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
This introduces features in the jsrust crate, so we can enable/disable
compilation for a specific platform at compile-time. It also does only select
the architecture targeted by the JIT, which should result in slightly lower
compilation times on every platform, and lower binary sizes too.
Differential Revision: https://phabricator.services.mozilla.com/D22280
--HG--
extra : moz-landing-system : lando
This introduces features in the jsrust crate, so we can enable/disable
compilation for a specific platform at compile-time. It also does only select
the architecture targeted by the JIT, which should result in slightly lower
compilation times on every platform, and lower binary sizes too.
Differential Revision: https://phabricator.services.mozilla.com/D22280
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
Rust ships with some natvis files that enable nicer display of Rust standard
library types in Microsoft's debuggers. rustc will add the right linker
options to include them when it invokes the linker but since we don't link
libxul with rustc we need to explicitly pass them to the linker ourselves.
This change locates all natvis files in the Rust sysroot and adds them
to the libxul link line.
Differential Revision: https://phabricator.services.mozilla.com/D16544
--HG--
extra : moz-landing-system : lando
Enough linux-based systems don't have libsecret that we can't make it a
requirement on linux. For those that do, however, we can dynamically load the
library at runtime. For those that don't, we can fall back to NSS.
Differential Revision: https://phabricator.services.mozilla.com/D9969
--HG--
extra : moz-landing-system : lando
Until rust 1.28, there was no stable way to change the allocator used by
rust code. In bug 1280578, we hooked HeadAlloc/HeapFree/HeapRealloc,
that the default rust system allocator uses. On other platforms, rust
code just ended up using malloc/free/realloc like everything else.
As of rust 1.28, though, it is now possible to use the GlobalAlloc trait
and the #[global_allocator] attribute to set an allocator. On Windows,
this can allow us to hook mozjemalloc directly, rather than using an
indirection through HeapAlloc/etc. (which require an extra call to
GetProcessHeap), so let's do this. On other platforms, this just ends up
doing the same thing as the default rust system allocator (except for
the memalign limit on 32-bits platforms).
We still need the HeapAlloc/etc. hooks for some C++ code using it, though.
Another benefit is that the HeapAlloc GlobalAlloc implementation needs
to do its own memalign, which it does by overallocating and aligning
manually. We obviously don't need to do this when we using
memalign/_aligned_malloc directly.
Differential Revision: https://phabricator.services.mozilla.com/D14820
--HG--
extra : moz-landing-system : lando
This removes the code added in bug 1458161, because the old versions of
rust that required it can't be used to build Gecko anymore. The variant
for newer versions of rust stays.
Differential Revision: https://phabricator.services.mozilla.com/D14528
--HG--
extra : moz-landing-system : lando
The current rust panic hook keeps a string for the crash reporter, and
goes on calling the default rust panic hook, which prints out a crash
stack... when RUST_BOOTSTRAP is set *and* when that works. Notably, on
both mac and Windows, it only really works for local builds, but fails
for debug builds from automation, although on automation itself, we also
do stackwalk from crash minidumps, which alleviates the problem.
Artifact debug builds are affected, though.
More importantly, C++ calls to e.g. MOZ_CRASH have a similar but
different behavior, in that they dump a stack trace on debug builds, by
default (with exceptions, see below for one). The format of those stack
traces is understood by the various fix*stack*py scripts under
tools/rb/, that are used by the various test harnesses both on
automation and locally.
Additionally, the current rust panic hook, as it calls the default rust
panic hook, ends up calling abort() on non-Windows platforms, which ends
up being verbosely redirected to mozalloc_abort per
https://dxr.mozilla.org/mozilla-central/rev/237e4c0633fda8e227b2ab3ab57e417c980a2811/memory/mozalloc/mozalloc_abort.cpp#79
which then calls MOZ_CRASH. Theoretically, /that/ would also print a
stack trace, but doesn't because currently the stack trace printing code
lives in libxul, and MOZ_CRASH only calls it when compiled from
libxul-code, which mozalloc_abort is not part of.
With this change, we make the rust panic handler call back into
MOZ_CRASH directly. This has multiple advantages:
- This is more consistent cross-platforms (Windows is not special
anymore).
- This is more consistent between C++ and rust (stack traces all look
the same, and can all be post-processed by fix*stack*py if need be)
- This is more consistent in behavior, where debug builds will show
those stack traces without caring about environment variables.
- It demangles C++ symbols in rust-initiated stack traces (for some
reason that didn't happen with the rust panic handler)
A few downsides:
- the loss of demangling for some rust symbols.
- the loss of addresses in the stacks, although they're not entirely
useful
- extra empty lines.
The first should be fixable later one. The latter two are arguably
something that should be consistent across C++ and rust, and should be
changed if necessary, independently of this patch.
Depends on D11719
Depends on D11719
Differential Revision: https://phabricator.services.mozilla.com/D11720
--HG--
extra : moz-landing-system : lando
The current rust panic hook keeps a string for the crash reporter, and
goes on calling the default rust panic hook, which prints out a crash
stack... when RUST_BOOTSTRAP is set *and* when that works. Notably, on
both mac and Windows, it only really works for local builds, but fails
for debug builds from automation, although on automation itself, we also
do stackwalk from crash minidumps, which alleviates the problem.
Artifact debug builds are affected, though.
More importantly, C++ calls to e.g. MOZ_CRASH have a similar but
different behavior, in that they dump a stack trace on debug builds, by
default (with exceptions, see below for one). The format of those stack
traces is understood by the various fix*stack*py scripts under
tools/rb/, that are used by the various test harnesses both on
automation and locally.
Additionally, the current rust panic hook, as it calls the default rust
panic hook, ends up calling abort() on non-Windows platforms, which ends
up being verbosely redirected to mozalloc_abort per
https://dxr.mozilla.org/mozilla-central/rev/237e4c0633fda8e227b2ab3ab57e417c980a2811/memory/mozalloc/mozalloc_abort.cpp#79
which then calls MOZ_CRASH. Theoretically, /that/ would also print a
stack trace, but doesn't because currently the stack trace printing code
lives in libxul, and MOZ_CRASH only calls it when compiled from
libxul-code, which mozalloc_abort is not part of.
With this change, we make the rust panic handler call back into
MOZ_CRASH directly. This has multiple advantages:
- This is more consistent cross-platforms (Windows is not special
anymore).
- This is more consistent between C++ and rust (stack traces all look
the same, and can all be post-processed by fix*stack*py if need be)
- This is more consistent in behavior, where debug builds will show
those stack traces without caring about environment variables.
- It demangles C++ symbols in rust-initiated stack traces (for some
reason that didn't happen with the rust panic handler)
A few downsides:
- the loss of demangling for some rust symbols.
- the loss of addresses in the stacks, although they're not entirely
useful
- extra empty lines.
The first should be fixable later one. The latter two are arguably
something that should be consistent across C++ and rust, and should be
changed if necessary, independently of this patch.
Depends on D11719
Differential Revision: https://phabricator.services.mozilla.com/D11720
--HG--
extra : moz-landing-system : lando
The current rust panic hook keeps a string for the crash reporter, and
goes on calling the default rust panic hook, which prints out a crash
stack... when RUST_BOOTSTRAP is set *and* when that works. Notably, on
both mac and Windows, it only really works for local builds, but fails
for debug builds from automation, although on automation itself, we also
do stackwalk from crash minidumps, which alleviates the problem.
Artifact debug builds are affected, though.
More importantly, C++ calls to e.g. MOZ_CRASH have a similar but
different behavior, in that they dump a stack trace on debug builds, by
default (with exceptions, see below for one). The format of those stack
traces is understood by the various fix*stack*py scripts under
tools/rb/, that are used by the various test harnesses both on
automation and locally.
Additionally, the current rust panic hook, as it calls the default rust
panic hook, ends up calling abort() on non-Windows platforms, which ends
up being verbosely redirected to mozalloc_abort per
https://dxr.mozilla.org/mozilla-central/rev/237e4c0633fda8e227b2ab3ab57e417c980a2811/memory/mozalloc/mozalloc_abort.cpp#79
which then calls MOZ_CRASH. Theoretically, /that/ would also print a
stack trace, but doesn't because currently the stack trace printing code
lives in libxul, and MOZ_CRASH only calls it when compiled from
libxul-code, which mozalloc_abort is not part of.
With this change, we make the rust panic handler call back into
MOZ_CRASH directly. This has multiple advantages:
- This is more consistent cross-platforms (Windows is not special
anymore).
- This is more consistent between C++ and rust (stack traces all look
the same, and can all be post-processed by fix*stack*py if need be)
- This is more consistent in behavior, where debug builds will show
those stack traces without caring about environment variables.
- It demangles C++ symbols in rust-initiated stack traces (for some
reason that didn't happen with the rust panic handler)
A few downsides:
- the loss of demangling for some rust symbols.
- the loss of addresses in the stacks, although they're not entirely
useful
- extra empty lines.
The first should be fixable later one. The latter two are arguably
something that should be consistent across C++ and rust, and should be
changed if necessary, independently of this patch.
Depends on D11719
Differential Revision: https://phabricator.services.mozilla.com/D11720
--HG--
extra : moz-landing-system : lando
This is the equivalent of the rustc-workspace-hack used by the rust build to
ensure cargo and RLS see the same set of features for dependencies so that
these dependencies may be reused by invocations of cargo for these two
projects. The trivial crate added specifies the union of the set of
features activated for a particular crate for each time it appears in the
dependency tree so that cargo will understand these dependencies to be
re-usable across cargo implementations. This eliminates re-building jsrust
and some of its dependencies twice, and reduces the number of crates compiled
in the tree by about 90 in testing on linux.
Differential Revision: https://phabricator.services.mozilla.com/D9041
Updating rkv to 0.5 enables us to un-vendor new-ordered-float, as rkv 0.4 is the last crate in the tree that depends on it.
It also enables us to un-vendor version 0.5 of uuid. We previously needed that version because multiple third-party crates depended on it, and we have limited control over third-party sub-dependencies. But rkv 0.4 was the last third-party crate that still depended on version 0.5 of uuid; rkv 0.5 depends on version 0.6 of uuid.
There would still be two internal crates that depend on version 0.5 of uuid: geckodriver and webrender_bindings. But we have more control over internal sub-dependencies, and we can update those two internal crates to depend on version 0.6 of uuid. This patch does so.
To summarize, this patch makes the following changes:
* rkv: 0.4 -> 0.5
* new-ordered-float: un-vendored
* geckodriver: uuid dependency 0.5 -> 0.6
* webrender_bindings: uuid dependency 0.5 -> 0.6
* uuid 0.5: un-vendored
* uuid 0.6: remains in tree
Differential Revision: https://phabricator.services.mozilla.com/D9160
--HG--
extra : moz-landing-system : lando
This is the equivalent of the rustc-workspace-hack used by the rust build to
ensure cargo and RLS see the same set of features for dependencies so that
these dependencies may be reused by invocations of cargo for these two
projects. The trivial crate added specifies the union of the set of
features activated for a particular crate for each time it appears in the
dependency tree so that cargo will understand these dependencies to be
re-usable across cargo implementations. This eliminates re-building jsrust
and some of its dependencies twice, and reduces the number of crates compiled
in the tree by about 90 in testing on linux.
Differential Revision: https://phabricator.services.mozilla.com/D9041
--HG--
extra : moz-landing-system : lando
Implemnt notification backend by Windows Toast API that is from Windows 8+.
Original patch is me and add some features by eoger.
Differential Revision: https://phabricator.services.mozilla.com/D3003
--HG--
extra : rebase_source : 0368f269e9adb2347621500b7c9d62c172a71e39
David Major
Cosmin Sabou
Mike Hommey
Lina Cambridge
Adam Gashlin
Mark Goodwin
Andreea Pavel
Benjamin Bouvier
Bogdan Tara
Matthew Gregan
Dorel Luca
Jonathan Kingston
Chris Peterson
Myk Melez
Bobby Holley
Harry Twyford
Ted Mielczarek
bitnotri
Dana Keeler
Sylvestre Ledru
Coroiu Cristina
Nathan Froyd
Andrew Osmond
Chris Manchester
Margareta Eliza Balazs
Edouard Oger
Ciure Andrei