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
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
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
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
1. Stop enabling -Wdeprecated-this-capture because it has no affect when compiling as C++17 and it's enabled by default with compiling as C++20.
2. Disable -Wdeprecated-this-capture warnings by changing "-Wno-error" to "-Wno". These warnings are enabled by default when compiling as C++20 and even just logging these warnings as non-fatal messages breaks the clang-plugin tests because the messages aren't in the tests' expected compiler output. We can't fix these warnings until after we default to -std=c++20 because the code change isn't backwards compatible with C++17.
3. Stop enabling -Wc++2a-compat because it causes build errors about valid C++20 code (that isn't backwards compatible with C++17) when compiling as C++20.
4. Remove -Wno-error=deprecated. I don't remember why it was needed to compile as C++20 when I added it two years ago (in bug 1781001), but it's no longer needed.
5. Disable -Wdeprecated-anon-enum-enum-conversion and -Wdeprecated-enum-enum-conversion warnings by changing "-Wno-error" to "-Wno". There are so many warnings in common shared header files, they overwhelm the compiler output. Fixing these warnings in bug 1791958 and bug 1791955, respectively, doesn't block defaulting to -std=c++20.
6. Remove -Wno-deprecated-pragma because it's not longer needed. It warns about C++20 deprecating ATOMIC_VAR_INIT in favor of std::atomic<int>. We used to have some warnings about ATOMIC_VAR_INIT, but I guess they've been fixed because we currently have no -Wdeprecated-pragma warnings.
Differential Revision: https://phabricator.services.mozilla.com/D205539
