The new rkv-based cert_storage database caused a Heap Unclassified regression because of memory that LMDB reserves when opening a database in read-write mode. Since cert_storage usage is read-heavy, this change claws back that regression by opening it in read-only mode except when changes are being made.
Differential Revision: https://phabricator.services.mozilla.com/D25098
--HG--
extra : moz-landing-system : lando
This adds the Firefox-required build.rs hack and reverts the commit
that added bitmasks in a way that depends on Rust 1.34 compiler
internals.
Depends on D20288
Differential Revision: https://phabricator.services.mozilla.com/D20289
--HG--
extra : moz-landing-system : lando
This changeset requires nightly Rust (to be changed in the next part).
Depends on D21891
Differential Revision: https://phabricator.services.mozilla.com/D20288
--HG--
rename : third_party/rust/simd/LICENSE-APACHE => third_party/rust/packed_simd/LICENSE-APACHE
rename : third_party/rust/simd/LICENSE-MIT => third_party/rust/packed_simd/LICENSE-MIT
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 adds `ThreadPtr{Handle, Holder}` to wrap an `XpCom` object
with thread-safe refcounting. These are analagous to
`nsMainThreadPtr{Handle, Holder}`, but can hold references to
objects from any thread, not just the main thread.
`ThreadPtrHolder` is similar to `ThreadBoundRefPtr`. However, it's
not possible to clone a `ThreadBoundRefPtr`, so it can't be shared
among tasks. This is fine for objects that are only used once, like
callbacks. However, `ThreadBoundRefPtr` doesn't work well for loggers
or event emitters, which might need to be called multiple times on
the owning thread.
Unlike a `ThreadBoundRefPtr`, it's allowed and expected to
clone and drop a `ThreadPtrHolder` on other threads. Internally,
the holder keeps an atomic refcount, and releases the wrapped object
on the owning thread once the count reaches zero.
This commit also changes `TaskRunnable` to support dispatching from
threads other than the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D20074
--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 reduces a lot the boilerplate that's needed in order to add simple binding
functions.
This starts using &Foo and Option<&Foo> instead, and as a result we need to
remove the servo_function_signatures test, which is a bit unfortunate.
I think it's worth though, this causes problems on some platforms (see bug
1534844), and messing up the functions signature is not something that I've ever
seen (other than bug 1308234, which already had all the FooBorrowed mess which
I'm removing).
Also, cbindgen understands references and Option<&Foo>, so it will be the way to
go in the future.
After this patch we can also remove HasSimpleFFI, but I've kept it for now since
I still use it in a few places, and this patch is quite big on its own.
Differential Revision: https://phabricator.services.mozilla.com/D24092
--HG--
extra : moz-landing-system : lando
The cleans up our WR use statements further, easying the merge conflicts.
Note: this PR is subject to instant rot, it is preferred to land quickly.
Differential Revision: https://phabricator.services.mozilla.com/D23373
--HG--
extra : moz-landing-system : lando
The cleans up our WR use statements further, easying the merge conflicts.
Note: this PR is subject to instant rot, it is preferred to land quickly.
Differential Revision: https://phabricator.services.mozilla.com/D23373
--HG--
extra : moz-landing-system : lando
This adds new code to provide the module-relative initial function offset for
each function, and adds checks that the bytecode / code offsets are correct.
Differential Revision: https://phabricator.services.mozilla.com/D22141
--HG--
rename : third_party/rust/cranelift-codegen-meta/src/base/settings.rs => third_party/rust/cranelift-codegen-meta/src/shared/settings.rs
rename : third_party/rust/cranelift-codegen-meta/src/base/types.rs => third_party/rust/cranelift-codegen-meta/src/shared/types.rs
extra : rebase_source : fd70523925d5d0655917bd9068f7ed35836c714a
extra : histedit_source : e64727d7be746dc3f327909db83f091602e259a9%2Cfc2a4335c2adada30a265a50fa76ef75a2b00bad
We've implemented several fixes to upstream `winapi-rs` that are
necessary for other work. We might as well make our upstream branch
track upstream `winapi-rs` instead of keeping track of the cherry-picked
fixes that we need.
Differential Revision: https://phabricator.services.mozilla.com/D22008
--HG--
extra : moz-landing-system : lando
example error
ERROR 2019-03-01T15:23:27Z: webrender::device::gl: (error) GL_INVALID_ENUM error generated. Invalid primitive mode.
thread 'main' panicked at 'Caught GL error 500 at 'draw_elements_instanced'', webrender/src/device/gl.rs:1098:17
note: Run with `RUST_BACKTRACE=1` for a backtrace.
Differential Revision: https://phabricator.services.mozilla.com/D21701
--HG--
extra : moz-landing-system : lando
The kvstore crate that landed in bug 1490496 uses an internal implementation of OwnedValue because the rkv crate's equivalent was insufficient at the time that kvstore was being developed.
rkv's OwnedValue has since evolved to support kvstore's use cases, and bug 1525392 is updating mozilla-central to the latest version of rkv; so we should replace kvstore's internal OwnedValue with rkv::OwnedValue.
Differential Revision: https://phabricator.services.mozilla.com/D19436
--HG--
extra : moz-landing-system : lando
Really sorry for the size of the patch :(
Only intentional behavior change is in the uses of HasLengthAndPercentage(),
where it's easier to do the right thing. The checks that used to check for
(IsCalcUnit() && CalcHasPercentage()) are wrong since bug 957915.
Differential Revision: https://phabricator.services.mozilla.com/D19553
This patch:
* Makes LengthPercentageOrAuto generic, and removes a bunch of code fo
LengthPercentageOrNone, which was used only for servo and now can use the
normal MaxLength (with a cfg() guard for the ExtremumLength variant).
* Shrinks MaxLength / MozLength's repr(C) reperesentation by reducing enum
nesting. The shrinking is in preparation for using them from C++ too, though
that'd be a different bug.
* Moves NonNegative usage to the proper places so that stuff for them can be
derived.
I did this on top of bug 1523071 to prove both that it could be possible and
that stuff wasn't too messy. It got a bit messy, but just because of a bug I
had fixed in bindgen long time ago already, so this updates bindgen's patch
version to grab a fix instead of ugly workarounds :)
Differential Revision: https://phabricator.services.mozilla.com/D17762
The fix for build bug 1512541 causes an Android build issue. The issue has been fixed upstream in LMDB's development branch, but the fix hasn't made it to LMDB's release branch. So I backported it to a branch in the mozilla/lmdb-rs repo, and this change switches to that branch to fix the Android build issue.
Differential Revision: https://phabricator.services.mozilla.com/D18767
--HG--
extra : moz-landing-system : lando
There's some new limited const fn support in stable, and this is the recommended
way to initialize atomics now.
If this for some reason doesn't compile in all platforms / versions we support
I'll just sprinkle some #[allow(deprecated)] instead.
Also, cargo changes the output of Cargo.lock, see
https://github.com/rust-lang/cargo/issues/6180. So also update those comments.
Differential Revision: https://phabricator.services.mozilla.com/D18495
--HG--
extra : moz-landing-system : lando
This patch moves u2f-hid-rs to 0.2.3 [1], which changes the dependency graph of
u2f-hid-rs to not directly rely on the low-level core-foundation-sys library, as
core-foundation has all the features u2f-hid-rs needs in 0.6.1+.
This patch vendors core-foundation 0.6.3 and core-foundation-sys 0.6.2 as a
consequence.
[1] https://github.com/jcjones/u2f-hid-rs/releases/tag/v0.2.3
[2] d1d36d1044
Differential Revision: https://phabricator.services.mozilla.com/D14569
--HG--
extra : moz-landing-system : lando
Update mp4parse-rust update script and pull the new version.
This update changes the mp4parse C-API. Specifically, each track can now
have multiple sample descriptions. Previously we'd just exposed the first for
the entire track, and if others were available they were not exposed via the
API. Because of the API change, we update the C++ interface with mp4parse-rust.
We now inspect the sample info to make sure they're consistent with the parsers
expectations:
- Only a single codec is present for a track, multiple codecs in a track will
result in us returning an error.
- Only 0 or 1 crypto info is present for a track, more than one set of info will
result in us returning an error.
We still generalize some of the first sample info to the samples of the track,
as we did before this patch. However, we will now catch the above cases
explicitly.
We now handle crypto information if it is not present on the first sample info.
The parser will iterate through sample infos and use the first set of crypto
info it finds (and fail if it finds 2+).
Differential Revision: https://phabricator.services.mozilla.com/D14107
--HG--
extra : moz-landing-system : lando
Update mp4parse-rust update script and pull the new version.
This update changes the mp4parse C-API. Specifically, each track can now
have multiple sample descriptions. Previously we'd just exposed the first for
the entire track, and if others were available they were not exposed via the
API. Because of the API change, we update the C++ interface with mp4parse-rust.
We now inspect the sample info to make sure they're consistent with the parsers
expectations:
- Only a single codec is present for a track, multiple codecs in a track will
result in us returning an error.
- Only 0 or 1 crypto info is present for a track, more than one set of info will
result in us returning an error.
We still generalize some of the first sample info to the samples of the track,
as we did before this patch. However, we will now catch the above cases
explicitly.
We now handle crypto information if it is not present on the first sample info.
The parser will iterate through sample infos and use the first set of crypto
info it finds (and fail if it finds 2+).
Differential Revision: https://phabricator.services.mozilla.com/D14107
--HG--
extra : moz-landing-system : lando
Generated with cargo update -p string_cache_codegen and ./mach vendor rust.
Differential Revision: https://phabricator.services.mozilla.com/D13649
--HG--
extra : moz-landing-system : lando
Just pushing this down my patch queue to avoid triggering large cargo
rebuilds when rebasing.
Depends on D13438
Differential Revision: https://phabricator.services.mozilla.com/D13439
--HG--
extra : moz-landing-system : lando
* Improves UTF-8 validation performance.
* Improves UTF-8 to UTF-16 decode performance.
* Improves non-Latin and Latin1-ish Latin single-byte encode performance.
* Improves code quality by addressing some clippy lints.
The optional legacy CJK encoder changes are not used by Firefox.
Differential Revision: https://phabricator.services.mozilla.com/D12514
--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
This pulls a new nom version, which is slightly unfortunate, but I do want some
of the fixes upstream, and it's build-only, so I think it's not a huge deal.
Differential Revision: https://phabricator.services.mozilla.com/D9362
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
Summary: The previous two changesets bump up a few dependencies. This is the companion mach rust vendor.
Test Plan: It builds.
Reviewers: ted
Tags: #secure-revision
Bug #: 1497446
--HG--
extra : amend_source : 6eeef28181e1e72891e1f3ad1d67b70cdf926e21
extra : histedit_source : e6af1b38e2272656c543f6c4f9778e80e6c75fd9
Only difference with current versions is the ability to use the crates
with stable rust without setting RUSTC_BOOTSTRAP globally ourselves.
Differential Revision: https://phabricator.services.mozilla.com/D7679
--HG--
extra : moz-landing-system : lando
* Update encoding_rs to 0.8.8.
* Change U+FEFD and U+FEFE to RTL in IS_RTL_PRESENTATION_FORM to make the
Rust and C++ code agree on what's RTL.
MozReview-Commit-ID: CuK6fN4pojG
Differential Revision: https://phabricator.services.mozilla.com/D7285
--HG--
extra : moz-landing-system : lando
Most importantly, this picks up "object" and "goblin" for ELF binary parsing.
We only use the ELF code from goblin, so the mach-O parsing code gets
eliminated by the linker. Overall, this increases the Android installer size
by 20KB.
Try pushes for reference:
before: https://treeherder.mozilla.org/#/jobs?repo=try&revision=834b56dc5ab3d63a43a32f740ee8212296ac726d&selectedJob=201600899
after: https://treeherder.mozilla.org/#/jobs?repo=try&revision=6983b27e8d3cb715d3b7e6cbd276683f6466e3cc&selectedJob=201600475
installer size: 34524820 -> 34542861 (34.52MB -> 34.54MB)
$ mach vendor rust
Updating registry `https://github.com/rust-lang/crates.io-index`
Adding goblin v0.0.17
Adding memmap v0.6.2
Adding miniz-sys v0.1.10
Adding object v0.10.0
Adding parity-wasm v0.31.3
Adding plain v0.2.3
Adding profiler_helper v0.1.0 (file:///Users/mstange/code/mozilla/tools/profiler/rust-helper)
Adding scroll v0.9.1
Adding scroll_derive v0.9.5
Adding syn v0.15.5
Adding thin-vec v0.1.0
Adding uuid v0.6.5
0:30.11 The following files exceed the filesize limit of 102400:
third_party/rust/miniz-sys/miniz.c
third_party/rust/syn-0.14.6/src/expr.rs
third_party/rust/syn-0.14.6/src/gen/fold.rs
third_party/rust/syn-0.14.6/src/gen/visit.rs
third_party/rust/syn-0.14.6/src/gen/visit_mut.rs
The syn dependency is not compiled for goblin, as far as I can tell - it's only
needed for the 'syn' feature of scroll_derive, and scroll does not ask for
scroll_derive/syn.
object -> goblin -> scroll -> scroll_derive -/-> syn
But it looks like other versions of syn were already in the tree.
Depends on D7021
Differential Revision: https://phabricator.services.mozilla.com/D7023
--HG--
rename : third_party/rust/syn/src/parsers.rs => third_party/rust/syn-0.14.6/src/parsers.rs
rename : third_party/rust/syn/src/verbatim.rs => third_party/rust/syn-0.14.6/src/verbatim.rs
rename : third_party/rust/uuid/.travis.yml => third_party/rust/uuid-0.5.1/.travis.yml
rename : third_party/rust/uuid/src/rustc_serialize.rs => third_party/rust/uuid-0.5.1/src/rustc_serialize.rs
rename : third_party/rust/uuid/src/serde.rs => third_party/rust/uuid-0.5.1/src/serde.rs
extra : moz-landing-system : lando
Most importantly, this picks up "object" and "goblin" for ELF binary parsing.
We only use the ELF code from goblin, so the mach-O parsing code gets
eliminated by the linker. Overall, this increases the Android installer size
by 20KB.
Try pushes for reference:
before: https://treeherder.mozilla.org/#/jobs?repo=try&revision=834b56dc5ab3d63a43a32f740ee8212296ac726d&selectedJob=201600899
after: https://treeherder.mozilla.org/#/jobs?repo=try&revision=6983b27e8d3cb715d3b7e6cbd276683f6466e3cc&selectedJob=201600475
installer size: 34524820 -> 34542861 (34.52MB -> 34.54MB)
$ mach vendor rust
Updating registry `https://github.com/rust-lang/crates.io-index`
Adding goblin v0.0.17
Adding memmap v0.6.2
Adding miniz-sys v0.1.10
Adding object v0.10.0
Adding parity-wasm v0.31.3
Adding plain v0.2.3
Adding profiler_helper v0.1.0 (file:///Users/mstange/code/mozilla/tools/profiler/rust-helper)
Adding scroll v0.9.1
Adding scroll_derive v0.9.5
Adding syn v0.15.5
Adding thin-vec v0.1.0
Adding uuid v0.6.5
0:30.11 The following files exceed the filesize limit of 102400:
third_party/rust/miniz-sys/miniz.c
third_party/rust/syn-0.14.6/src/expr.rs
third_party/rust/syn-0.14.6/src/gen/fold.rs
third_party/rust/syn-0.14.6/src/gen/visit.rs
third_party/rust/syn-0.14.6/src/gen/visit_mut.rs
The syn dependency is not compiled for goblin, as far as I can tell - it's only
needed for the 'syn' feature of scroll_derive, and scroll does not ask for
scroll_derive/syn.
object -> goblin -> scroll -> scroll_derive -/-> syn
But it looks like other versions of syn were already in the tree.
Depends on D7021
Differential Revision: https://phabricator.services.mozilla.com/D7023
--HG--
rename : third_party/rust/syn/src/parsers.rs => third_party/rust/syn-0.14.6/src/parsers.rs
rename : third_party/rust/syn/src/verbatim.rs => third_party/rust/syn-0.14.6/src/verbatim.rs
rename : third_party/rust/uuid/.travis.yml => third_party/rust/uuid-0.5.1/.travis.yml
rename : third_party/rust/uuid/src/rustc_serialize.rs => third_party/rust/uuid-0.5.1/src/rustc_serialize.rs
rename : third_party/rust/uuid/src/serde.rs => third_party/rust/uuid-0.5.1/src/serde.rs
extra : moz-landing-system : lando
We had a mix of 0.6.2 and 0.6.5 (which is the current release),
this unifies to the latest version. It also enables the union
feature which removes the discriminant, reducing memory usage.
This cherry-picks servo/servo#21746.
log 0.3.9 is still there because tokio-uds 0.1.7, which is a
dependency of audioipc, still depends on ^0.3. A separate bug will
be filed on WebRTC to upgrade their tokio-uds dependency.
Cameron McCormack
Myk Melez
Nan Jiang
Emilio Cobos Álvarez
Narcis Beleuzu
Coroiu Cristina
Bastien Orivel
Mike Hommey
shindli
Henri Sivonen
Lina Cambridge
Adam Gashlin
Barret Rennie
Mark Goodwin
Andreea Pavel
Dzmitry Malyshau
Nupur Baghel
Gurzau Raul
Bobby Holley
Benjamin Bouvier
Jan Varga
Matthew Gregan
Dorel Luca
Nathan Froyd
Nicolas Silva
Nika Layzell
Kartikaya Gupta
Chris Manchester
Matt Brubeck
Cosmin Sabou
Jamie Nicol
Csoregi Natalia
Bogdan Tara
Glenn Watson
Jonathan Kingston
Henrik Skupin
Daniel Varga
Lee Salzman
Razvan Maries
WR Updater Bot
Shanavas M
Simon Sapin
J.C. Jones
Bryce Van Dyk
Alex Gaynor
Markus Stange
Valentin Gosu
Dan Gohman
Nathan Froyd
Margareta Eliza Balazs
Noemi Erli
Sebastian Hengst
David Teller
Jeff Muizelaar
Andreas Tolfsen
Matt Brubeck
Andre Bogus