The only use of this type used to be carrying around an owning reference
to a thread-local. However, since bug 1577439 we're leaking the
allocation intentionally, so we can simplify the code to explicitly use
`Box::leak()`, which in turn removes all unsafe usage around these, and
allows us to drop the owning_ref dependency altogether.
Differential Revision: https://phabricator.services.mozilla.com/D209912
Because fallible_collections pulls hashbrown 0.13, we also upgrade
hashlink to 0.8.2, which updates to that version as well. Those were the
last two uses of hashbrown 0.12, so we can update the fake hashbrown
0.12 to 0.13.
We could skip the upgrade of hashlink, but that would leave us with two
fake hashbrowns, and we'd hit https://github.com/rust-lang/cargo/issues/13405
Differential Revision: https://phabricator.services.mozilla.com/D209317
Some automation tiers ultimately end up calling normal tiers, which
will print their own BUILDSTATUS already. This kind of didn't cause
problems before bug 1859011 presumably because of buffering of the
automation tier output, but is now causing problems because the tier
monitor doesn't want to see a tier start multiple times.
Also, now that bug 1859011 made automation tiers buffered by command
rather than by target, we don't need the hack with automation-start,
simplifying the setup.
Differential Revision: https://phabricator.services.mozilla.com/D209095
Mach can currently only run on Python version 3.8 or higher, so it
doesn't make sense to continue having dead code that provides support
for Python2.
Differential Revision: https://phabricator.services.mozilla.com/D209030
@file are supported by gcc since gcc 7 and by clang since clang 3.x,
which removes the need for linker script to list input files.
We cannot directly use @file from the compiler driver (it would expand
to a large number of arguments and hit the linker limit) so pass
-Wl,@FILE instead, which is supported since binutils 2.17.
As a side effect this removes the LTO dependency from the check.
Differential Revision: https://phabricator.services.mozilla.com/D207839
@file are supported by gcc since gcc 7 and by clang since clang 3.x,
which removes the need for linker script to list input files.
We cannot directly use @file from the compiler driver (it would expand
to a large number of arguments and hit the linker limit) so pass
-Wl,@FILE instead, which is supported since binutils 2.17.
As a side effect this removes the LTO dependency from the check.
Differential Revision: https://phabricator.services.mozilla.com/D207839
Reverting the entire commit that is causing problems has caused a number
of conflicts with further changes in LLVM in the past year and a half,
making us have to revert a bunch of other patches.
Instead of doing that, we just revert the small part of the original
change that is causing the problem, avoiding conflicts with newer
changes. This also gives us a better hint at what's really going on.
Differential Revision: https://phabricator.services.mozilla.com/D207829
The -ldl flag was previously set globally, it's now set for the libs
that use it.
Also rationalize the difference between HAVE_DLOPEN and HAVE_DLFCN_H.
Differential Revision: https://phabricator.services.mozilla.com/D203594
This synchronization is now handled in the downstream repositories. In
the case of WebRender by the Servo project and in the case of qcms by a
Gecko-managed GitHub Action. This change removes the github-sync task
from mozilla-central.
Differential Revision: https://phabricator.services.mozilla.com/D204787
Update:
- UniFFI to 0.27.1
- Glean to 59.0.0
- App-services to a recent version
This removes the need for the goblin build hack, although we still have
duplicate versions of goblin since UniFFI is ahead of the moz-central
version. I think that should be easy to resolve as a follow-up.
Updating uniffi-bindget-gecko-js based on upstream changes:
- Clone objects before lowering them
(https://github.com/mozilla/uniffi-rs/pull/1880)
- Use u64 for the RustBuffer length and capacity field
(https://github.com/mozilla/uniffi-rs/pull/1978)
I didn't implement the new callback interface VTable code. Instead I
simply disabled the one fixture that tests it. I'd rather implement
https://bugzilla.mozilla.org/show_bug.cgi?id=1888668 first, since that
will simplify the process a bunch. The only real-world use-case for
callbacks that I know of is Mark's logging changes, but that will
require implementing trait interfaces anyways so I'd rather wait than
write a bunch of C++ code that we then throw away.
Differential Revision: https://phabricator.services.mozilla.com/D206130
Added new secret data storing the release keys. Modifying scripts to hook them up. Testing will be done thoroughly with try and release builds to confirm that pinning works on newer machines and falls back to the old mechanism on older machines.
Differential Revision: https://phabricator.services.mozilla.com/D205361
We're currently applying patches to clang to work around some yet
unidentified problem with some change that, when applied to
llvm-symbolizer, makes tsan tests timeout for some reason.
Those patches regularly conflict with newer changes to LLVM, blocking
the clang build. We however actually don't need to apply these reverts
to clang itself, only to llvm-symbolizer, which we build separately. So
we do that, and fix the llvm-symbolizer-trunk task to revert the new
conflicting upstream patches.
Differential Revision: https://phabricator.services.mozilla.com/D206727
Update:
- UniFFI to 0.27.1
- Glean to 59.0.0
- App-services to a recent version
This removes the need for the goblin build hack, although we still have
duplicate versions of goblin since UniFFI is ahead of the moz-central
version. I think that should be easy to resolve as a follow-up.
Updating uniffi-bindget-gecko-js based on upstream changes:
- Clone objects before lowering them
(https://github.com/mozilla/uniffi-rs/pull/1880)
- Use u64 for the RustBuffer length and capacity field
(https://github.com/mozilla/uniffi-rs/pull/1978)
I didn't implement the new callback interface VTable code. Instead I
simply disabled the one fixture that tests it. I'd rather implement
https://bugzilla.mozilla.org/show_bug.cgi?id=1888668 first, since that
will simplify the process a bunch. The only real-world use-case for
callbacks that I know of is Mark's logging changes, but that will
require implementing trait interfaces anyways so I'd rather wait than
write a bunch of C++ code that we then throw away.
Differential Revision: https://phabricator.services.mozilla.com/D206130
