Following a suggestion from :mkmelin, this seems like an optimal solution: the overriding/duplication in m-c is removed, and all users get a more powerful default choice that they're still able to override with their own, should they so wish.
For clarity and to match other `about:` pages, the shared code is placed under `toolkit/content/`, and all content under `docshell/resources/` is removed.
Differential Revision: https://phabricator.services.mozilla.com/D156478
Remove all the thread names only used in tests from ThreadAllows.txt.
Instead, list the test files that create them in ThreadFileAllows.txt.
Differential Revision: https://phabricator.services.mozilla.com/D157762
Filenames alone do not uniquely identify files in the Mozilla codebase.
Allow specification of path-elements alongside filenames.
Differential Revision: https://phabricator.services.mozilla.com/D157761
Expand the processor for ThreadAllows.txt and ThreadFileAllows.txt to
also recognize and permit comments prefixed by `#`.
Differential Revision: https://phabricator.services.mozilla.com/D157760
Remove all the thread names only used in tests from ThreadAllows.txt.
Instead, list the test files that create them in ThreadFileAllows.txt.
Differential Revision: https://phabricator.services.mozilla.com/D157762
Filenames alone do not uniquely identify files in the Mozilla codebase.
Allow specification of path-elements alongside filenames.
Differential Revision: https://phabricator.services.mozilla.com/D157761
Expand the processor for ThreadAllows.txt and ThreadFileAllows.txt to
also recognize and permit comments prefixed by `#`.
Differential Revision: https://phabricator.services.mozilla.com/D157760
Whenever some activity starts on the thread we are monitoring, we create a timer that targets the BHMgr Monitor thread (where we capture hang stacks).
Whenever the activity stops, we cancel the timer.
In the past, this would have been very expensive because the Timer thread used to wake-up every time a timer was added or removed. This is no longer true, as we optimized the wake-up behavior of the timer thread to only wake-up when it actually needs to.
Differential Revision: https://phabricator.services.mozilla.com/D154141
In one place, we specifically check for softfp and do the right thing,
while in another we omit doing it, while at the same time we already
have a check in arm.configure that gives us (mostly) the flags we want.
Differential Revision: https://phabricator.services.mozilla.com/D157687
This patch was made to guard Update functionality from being called in BrowserGlue.jsm if Firefox was not built with support for the Updater. However, it also ended up touching the updater build configuration. I discovered while testing this patch that building with `--disable-updater` does not imply `--disable-maintenance-service` or `--disable-update-agent`. So I fixed that issue as well. Once that was fixed, I could change some other code that checked `AppConstants.MOZ_UPDATER && AppConstants.MOZ_UPDATE_AGENT` since that is now equivilant to `AppConstants.MOZ_UPDATE_AGENT`.
Differential Revision: https://phabricator.services.mozilla.com/D156902
There are some ABI issues with libc++ headers in clang 15. The main
reason we are shipping libc++ with our clang is that the macos SDK,
up to and including 11.1, only contained the libc++ libraries, but
not the headers. The first SDK that contains the headers is 11.3
(there is no 11.2, at least publicly available), and we're now using
it.
Another problem with libc++ is that the way we currently build it is
deprecated and is going to yields hard errors soon enough on clang
trunk.
The simplest thing to do right now is to just stop shipping libc++.
Eventually, we may want to ship it correctly in a different way, for
all platforms, which was not happening anyways.
Differential Revision: https://phabricator.services.mozilla.com/D156283
`HAS_CONNECTX` is not used in `netwerk/protocol/http` as of bug 1689604.
In NSPR, it is used to enable the use of `connectx`, which is available
since macOS 10.11, and we target 10.12, which means it's always
available, so we don't need to check for it based on the target version
(and checking the host version was wrong, too).
Differential Revision: https://phabricator.services.mozilla.com/D156275
Because the relevant SDK is not installed on the mac workers, we pull it
via fetches and adjust the plain build mozconfig as well as mozconfigs
for rusttest, grouping most things in build/macosx/mozconfig.common.
And because the SDK itself now has all the relevant headers, we don't
need the old check for system C++ headers (which also happens to have
outdated instructions)
Differential Revision: https://phabricator.services.mozilla.com/D156280
We keep the older 11.0 and 10.11 SDKs for openh264.
Ideally, we'd rename the SDK directory not to contain its version, but
ld64 actually relies on the directory name to figure out the platform
version when it's not given to it, which it's not. We can make clang do
that, but it's rather involved (because it also requires setting up the
host linker properly, which we don't do), so we just go the easy route
and keep the SDK version in its directory.
Differential Revision: https://phabricator.services.mozilla.com/D156279
Currently, when building clang for mac, which we cross-compile, we're
always passing a x86-64 target, even on arm64. This cancels out with the
LLVM build system adding `-arch arm64`, so it worked fine... until clang
15, where some things end up being built without `-arch arm64` and
things end up broken.
Differential Revision: https://phabricator.services.mozilla.com/D156258
This had been attempted in bug 1747532 but failed for some reason and we
limited it to local builds with clang >= 13. Now enable by default on any
build with clang >= 14.
Differential Revision: https://phabricator.services.mozilla.com/D156267