Also:
- deactivate LLVM_SYMBOLIZER on android mozconfig as we don't cross compile it yet.
- enforce LLVM_SYMBOLIZER when fuzzing is on
- fix osx packaging to include llvm-symbolizer when fuzzing, and provide
it through tc
Differential Revision: https://phabricator.services.mozilla.com/D210190
Adds two new checks:
- Checks that the directory pointed to by the `MOZILLABUILD` environment variable exists, and prints it.
- Checks if the version meets a minimum version, and displays an error message if it doesn't.
These checks will only run on Windows.
The specified minimum version of MozillaBuild is `4.0` as it is reasonably recent. `4.1` has only been out a few months, and is not strictly needed, but we could up the minimum to `4.1` relatively soon.
Differential Revision: https://phabricator.services.mozilla.com/D107835
They existed to revert things that conflicted with other things being
reverted, but those things are not reverted anymore as of bug 1892128.
Differential Revision: https://phabricator.services.mozilla.com/D211807
These tests would fail if we automatically add a HTTPS-First exception. So this
patch either removes those exceptions again throughout the tests, or disables
the adding of automatic exceptions via a pref.
Differential Revision: https://phabricator.services.mozilla.com/D204757
This patch addresses the problem that we currently collect HTTPS-First telemetry
for sites that are not reachable at all, be it through always causing a error or
through always timing out.
- On a downgrade, do not collect telemetry instantly, but instead save the
telemetry data in the load state for the downgraded request
- That telemetry data will then be copied over into the document load listener
of the new request
- On a successful request, if we have downgrade data in the load listener, we
collect the downgrade telemetry, as the downgrade seems to have been
successful
- Similar to the downgrade case, we only count the upgrade metric once we
encounter a successful request annotated with the information that it was
upgraded by HTTPS-First, instead of counting it instantly on the decision to
upgrade. This also means the upgrade metric will not include loads that are
downgraded again anymore
- Add a testcase for a site which is neither reachable via HTTP nor HTTPS, and
ensure no telemetry is collected
Differential Revision: https://phabricator.services.mozilla.com/D210792
We don't check for pkg-config on some platforms (Windows, OSX, Android).
On those platforms, calling 'pkg_check_modules' will not work. Adding
the same 'when' used for the 'pkg_config' check to all the options that
end up calling 'pkg_check_modules' effectively disables them, and prevents
'pkg_check_modules' from being called.
Differential Revision: https://phabricator.services.mozilla.com/D150649
We don't check for pkg-config on some platforms (Windows, OSX, Android).
On those platforms, calling 'pkg_check_modules' will not work. Adding
the same 'when' used for the 'pkg_config' check to all the options that
end up calling 'pkg_check_modules' effectively disables them, and prevents
'pkg_check_modules' from being called.
Differential Revision: https://phabricator.services.mozilla.com/D150649
Now that WGPU has upgraded its dependency on `libloading`, we can
finally remove our fake `libloading` 0.7 crate! 🙌
I found this audit and review easiest to do by generating a diff. that
ignores whitespace-only differences. In my case, I did the following:
```
git diff --ignore-space-at-eol --ignore-space-change --ignore-all-space --ignore-blank-lines
```
Differential Revision: https://phabricator.services.mozilla.com/D209290
Get read of -pthreads because (according to gcc info page) it's only
there on solaris and as an alias to -pthread.
-D_REENTRANT is always defined by gcc and clang when -pthreads is on.
-D_THREAD_SAFE is only defined on AIX by clang
so get rid of the related actions.
libpthreads is an AIX thing, I assume we can remove it too.
c/cxx flags are always added to the linker flags, so don't do any
linker-related addition.
Differential Revision: https://phabricator.services.mozilla.com/D203687
The location of the built libraries was changed by bug 1459764.
Additionally update the search paths in the .lldbinit file that gets
put in the objdir during build.
Differential Revision: https://phabricator.services.mozilla.com/D210667
Actually remove the check for demangle, no supported target need that
check.
Also make library dependencies explicit instead of relying on "$LIBS".
Differential Revision: https://phabricator.services.mozilla.com/D203637
We can't add the flag to EXE files unless we do either
* Make the CRT an SxS assembly (bug 1733734) or
* Ship the redistributable installer to install the CRT to System32.
Because otherwise firefox.exe will no longer be able to find the CRT.
Differential Revision: https://phabricator.services.mozilla.com/D210639
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
Actually remove the check for demangle, no supported target need that
check.
Also make library dependencies explicit instead of relying on "$LIBS".
Differential Revision: https://phabricator.services.mozilla.com/D203637
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
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
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
The Visual Studio manifest for VS 2022 doesn't contain the SDK
Debuggers, unlike the standalone Windows SDK. This seems like a mistake
on Microsoft's part, and until we either dump the dependency on the tool
we use from there or it's fixed, we add it manually, copying the
relevant payloads information from the VS 2019 manifest.
To avoid the same from happening again in the future (like, if we update
the yaml with the command in its header, those will go away), we also
make pdbstr non-optional on CI, so that builds would fail if that
happens.
Differential Revision: https://phabricator.services.mozilla.com/D204002
This issue was introduced when D194599 moved the 'suggest' command logic
earlier in the mach initialization, so there was not a try/catch wrapper
to handle the error nicely.
Differential Revision: https://phabricator.services.mozilla.com/D204100
This changes the semantics of bootstrapping substantially, but all for
the simpler.
- --disable-bootstrap now prevents bootstrapped toolchains from being used
entirely, even if they are present.
- --enable-bootstrap still automatically downloads missing or
out-of-date toolchains, and is still only the default when building off
a VCS checkout of mozilla-central.
- When neither option is given on another tree than a VCS checkout of
mozilla-central, already bootstrapped toolchains are prioritized, but
missing toolchains are not downloaded, and outdated toolchains are not
updated.
- --enable-bootstrap=no-update can now be used to replace the previous
behavior of --disable-bootstrap, to avoid the automatic update of
already bootstrapped toolchains, with the difference that missing
toolchains are still automatically bootstrapped.
This has the downside of making the semantics of the per-toolchain
opt-in/opt-out mechanics introduced in bug 1828027 kind of confusing,
but I'm keeping reworking that, or entirely removing it for a followup.
Differential Revision: https://phabricator.services.mozilla.com/D188315