Two changes happened during the LLVM 11 timeframe that break our Searchfox plugin.
First, the conversion from `llvm::StringRef` to `std::string` became explicit: adcd026838 This is easy enough to fix in a version-agnostic way.
Second, `mangleCXXCtor` no longer exists: 29e1a16be8 Since there isn't a one-size-fits-all fix, I had to use an ifdef. I mostly cargo-culted the change from 29e1a16be8 (diff-dac09655ff6a54658c320a28a6ea297c).
Differential Revision: https://phabricator.services.mozilla.com/D83838
LLVM 11 introduces a hard requirement for SDK 10.12 in order to build for Mac. We want to keep building older LLVMs with 10.11 though, so this patch adds some flexibility so that build-clang can make use of whatever SDK package a particular task pulls from tooltool (but still requesting a deployment target of 10.11).
Differential Revision: https://phabricator.services.mozilla.com/D82621
After bug 1651806, we're trying to caution people against running `mach build $A_SPECIFIC_TARGET` because it's not generally supported. `dumbmake` is a piece of infrastructure that attempts to make this use case a little bit more useable, but it was always supposed to be a stopgap. There doesn't seem to be a need for it any more.
Differential Revision: https://phabricator.services.mozilla.com/D83136
This is where the `compare-mozconfig` test properly belongs, and `mozbuild` tests already re-run every time a `mozboot` file changes.
Differential Revision: https://phabricator.services.mozilla.com/D83130
Add an action that will trigger a task that runs
`mach release push-scriptworker-canary`
to test a new scriptworker deployment.
Differential Revision: https://phabricator.services.mozilla.com/D82821
clang/LLVM's build scripts can turn these on on their own, but explicitly
setting what we want is better than guessing. The change is not huge, maybe
~2-3% on the major shared libraries (`libclang`, `libclang-cpp`, `libLLVM`),
about 1% on the overall `.tar.zst` size, but every little bit counts, right?
Differential Revision: https://phabricator.services.mozilla.com/D82896
2020-06-26 Kevin Jacobs <kjacobs@mozilla.com>
* automation/abi-check/expected-report-libssl3.so.txt, automation/abi-
check/previous-nss-release, lib/nss/nss.h, lib/softoken/softkver.h,
lib/util/nssutil.h:
Set version numbers to 3.55 beta
[332ab7db68ba]
2020-06-25 Kevin Jacobs <kjacobs@mozilla.com>
* tests/all.sh:
Bug 1649190 - Run cipher, sdr, and ocsp tests under standard test
cycle.
[f373809abfc0]
2020-06-15 Kevin Jacobs <kjacobs@mozilla.com>
* gtests/common/testvectors/p256ecdsa-sha256-vectors.h,
gtests/common/testvectors/p384ecdsa-sha384-vectors.h,
gtests/common/testvectors/p521ecdsa-sha512-vectors.h,
gtests/common/testvectors_base/test-structs.h,
gtests/common/wycheproof/genTestVectors.py,
gtests/pk11_gtest/pk11_ecdsa_unittest.cc:
Bug 1649226 - Add Wycheproof ECDSA tests.
[41292ff7f545]
2020-06-30 Benjamin Beurdouche <bbeurdouche@mozilla.com>
* lib/pkcs12/p12d.c:
Bug 1649322 - Fix null pointer passed as argument in
pk11wrap/pk11pbe.c:1246 r=kjacobs
[cc43ebf5bf88]
2020-06-30 Danh <congdanhqx@gmail.com>
* coreconf/arch.mk, coreconf/config.mk, lib/freebl/Makefile:
Bug 1646594 - Enable AVX2 if applicable on x86_64 with make 4.3
r=bbeurdouche
[b579895aceb0]
2020-07-02 Benjamin Beurdouche <bbeurdouche@mozilla.com>
* lib/ssl/ssl3con.c:
Bug 1649316 - Prevent memcmp to be called with a zero length in
ssl/ssl3con.c:6621 r=kjacobs
[8fe9213d0551]
2020-07-02 Alexander Scheel <ascheel@redhat.com>
* lib/cryptohi/secvfy.c:
Bug 1649487 - Fix bad assert in VFY_EndWithSignature. r=jcj
[c9438b528103]
2020-07-06 Dana Keeler <dkeeler@mozilla.com>
* automation/abi-check/expected-report-libnss3.so.txt,
gtests/pk11_gtest/pk11_find_certs_unittest.cc, lib/nss/nss.def,
lib/pk11wrap/pk11cert.c, lib/pk11wrap/pk11pub.h:
Bug 1649633 - add PK11_FindEncodedCertInSlot r=kjacobs,jcj
PK11_FindEncodedCertInSlot can be used to determine the PKCS#11
object handle of an encoded certificate in a given slot. If the
given certificate does not exist in that slot, CK_INVALID_HANDLE is
returned.
[32fe710a942f]
* gtests/pk11_gtest/pk11_find_certs_unittest.cc:
Bug 1649633 - follow-up to make test comparisons in
pk11_find_certs_unittest.cc yoda comparisons r=kjacobs
[424dae31a1c1]
2020-07-07 Kevin Jacobs <kjacobs@mozilla.com>
* gtests/pk11_gtest/pk11_rsapkcs1_unittest.cc, lib/freebl/rsapkcs.c:
Bug 1067214 - Check minimum padding in RSA_CheckSignRecover.
r=rrelyea
This patch adds a check to `RSA_CheckSignRecover` enforcing a
minimum padding length of 8 bytes for PKCS #1 v1.5-formatted
signatures. In practice, RSA key size requirements already ensure
this requirement is met, but smaller (read: broken) key sizes can be
used via configuration overrides, and NSS should just follow the
spec.
[e5324bd5a885]
2020-07-08 Kevin Jacobs <kjacobs@mozilla.com>
* gtests/ssl_gtest/libssl_internals.c,
gtests/ssl_gtest/libssl_internals.h,
gtests/ssl_gtest/ssl_record_unittest.cc,
gtests/ssl_gtest/tls_agent.cc, gtests/ssl_gtest/tls_agent.h,
lib/ssl/dtls13con.c, lib/ssl/dtls13con.h, lib/ssl/ssl3con.c,
lib/ssl/ssl3prot.h, lib/ssl/sslspec.h, lib/ssl/sslt.h,
lib/ssl/tls13con.c, lib/ssl/tls13exthandle.c:
Bug 1647752 - Update DTLS 1.3 implementation to draft-38. r=mt
This patch updates DTLS 1.3 to draft-38. Specifically:
# `ssl_ct_ack` value changes from 25 to 26. # AEAD limits in
`tls13_UnprotectRecord` enforce a maximum of 2^36-1 (as we only
support GCM/ChaCha20 AEADs) decryption failures before the
connection is closed. # Post-handshake authentication will no longer
be negotiated in DTLS 1.3. This allows us to side-step the more
convoluted state machine requirements.
[132a87fc8689]
2020-07-09 Benjamin Beurdouche <bbeurdouche@mozilla.com>
* lib/pk11wrap/pk11pbe.c, lib/pkcs12/p12d.c:
Bug 1649322 - Fix null pointer passed as argument in
pk11wrap/pk11pbe.c:1246 r=kjacobs
This is a fixup patch that reverts https://hg.mozilla.org/projects/n
ss/rev/cc43ebf5bf88355837c5fafa2f3c46e37626707a and adds a null
check around the memcpy in question.
[80bea0e22b20]
2020-07-09 J.C. Jones <jjones@mozilla.com>
* lib/softoken/pkcs11.c:
Bug 1651520 - slotLock race in NSC_GetTokenInfo r=kjacobs
Basically, NSC_GetTokenInfo doesn't lock slot->slotLock before
accessing slot after obtaining it, even though slotLock is defined
as its lock. [0]
[0] https://searchfox.org/nss/rev/a412e70e55218aaf670f1f10322fa734d8
a9fbde/lib/softoken/pkcs11i.h#320-321
[58c2abd7404e] [tip]
Differential Revision: https://phabricator.services.mozilla.com/D82466
This is just re-arranging the deckchairs in preparation for adding an
"update programs" build project. Here "update programs" refers to the
various standalone binaries we produce in order to update Firefox.
There's not strong conceptual coherence between them; rather, it's the
pieces that the Install/Update team generally work on.
Differential Revision: https://phabricator.services.mozilla.com/D82643
The current setup sets /some/ flags via CLANGCL_ASFLAGS (handling of x86
is notably missing, for instance), and uses "clang-cl" as the assembler,
assuming it's in $PATH.
This can be simplified by just using `CC`, which will contain the full
path to "clang-cl" and the right flags for the targets, which makes
CLANGCL_ASFLAGS unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D82660
This is a partial revert of bug 1647628.
The ImageBridgeChild's thread is used to dispatch synchronous tasks by its consumers.
While the background taskqueue is using a single thread threadpool, this would prevent many places to also use a background taskqueue that could end up calling the ImageBridgeChild.
Differential Revision: https://phabricator.services.mozilla.com/D82395
This patch includes content from the following places.
- Lina's "Getting Rusty: How to ship an XPCOM component in Firefox" slide deck.
- Zibi's "Rust <--> C/C++ FFI for newbies" gist.
It also links to Emilio's "FFI patterns #1 - Complex Rust data structures
exposed seamlessly to C++" blog post. I was going to include that content, but
it's very long, so I have omitted it for now.
Differential Revision: https://phabricator.services.mozilla.com/D81963
Source history does not give any good clues about why this line was added in the first place. In any case, LLVM trunk currently has build bustage when threads are disabled. We could work around the bustage and/or wait for a fix, but it seems like threads are a good thing to have in general nowadays. Maybe this could help with LTO build times.
Differential Revision: https://phabricator.services.mozilla.com/D82447
The logic was apparently initially copied from the compositor thread which too got migrated to nsThread in bug 1634253, so we re-use that same logic again.
This allows to remove all use of the Google's MessageLoop.
Differential Revision: https://phabricator.services.mozilla.com/D81974
There's a small race that can happen when the remote decoder gets shutdown during xpcom shutdown; that would cause GetCurrentSerialEventTarget to return null. Leading to an assertion failure in ActorLifecycleProxy thread-safety check when PRemoteDecoderManagerParent gets destroyed.
So we use a background taskqueue instead and cleanup a bit the threading code in there allowed thanks to the TaskQueue ability to not require an explicit shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D81287
Because jar_maker is not in the libs tier, we also rename the libs-%
targets for l10n repacks to l10n-%, which make it clearer what they are
for.
And because multilocale.txt is both a GeneratedFile and a file that is
generated (and installed) via manual build rules, keeping it in the misc
target actually breaks building in toolkit/locales during l10n repacks,
so move it to libs for now.
Differential Revision: https://phabricator.services.mozilla.com/D81766
We get a lot of bugs about building Firefox for Android not working, and there's been ongoing confusion about whether this is something that does work or who has ever worked. The warning should hopefully clarify the current situation for people.
Differential Revision: https://phabricator.services.mozilla.com/D81585
There's a small race that can happen when the remote decoder gets shutdown during xpcom shutdown; that would cause GetCurrentSerialEventTarget to return null. Leading to an assertion failure in ActorLifecycleProxy thread-safety check when PRemoteDecoderManagerParent gets destroyed.
So we use a background taskqueue instead and cleanup a bit the threading code in there allowed thanks to the TaskQueue ability to not require an explicit shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D81287
clang 11 will stop using full paths in PGO dependentlib declarations, so we need to tell the linker where to find clang_rt.profile-x86_64.lib.
This is roughly a revert of bug 1621552.
Differential Revision: https://phabricator.services.mozilla.com/D81244
Some of the testing info is from the Oxidation wiki, and the logging info is
largely from a dev-platform email by Valentin. The other parts I wrote from
scratch.
The commit also makes some small improvements to the Rust build docs.
Differential Revision: https://phabricator.services.mozilla.com/D81017
And add suppressions for the new errors that this adds to the valgrind
run. It's not clear if it's a legitimate thing that LLVM does that
valgrind doesn't cope with, like many others, but the fact is running
valgrind on a PGO/LTO build doesn't show these errors, so we're not
actually shipping them anyways (but does show _different_ errors that we
don't see on the build the valgrind jobs do)
Differential Revision: https://phabricator.services.mozilla.com/D81016
In clang-11 the flag's behavior became the default, and in fact the flag is no longer accepted so we get an unrecognized option error.
Differential Revision: https://phabricator.services.mozilla.com/D81124
The added material comes from the Oxidation wiki's FAQ and the "Building
Firefox with Rust code" MDN page:
https://wiki.developer.mozilla.org/en-US/docs/Mozilla/Firefox/Building_Firefox_with_Rust_code
Once this commit lands, I will (a) remove the wiki FAQ entries, and (b) replace
the contents of that MDN page with a link to these build docs. There's no point
having overlapping docs, and in-tree is the best place for this information.
This commit also makes the capitalization of sub-headings more consistent.
Differential Revision: https://phabricator.services.mozilla.com/D79956
When linking a weak symbol in an object against a library where the
symbol is provided with a version, the final binary get a weak versioned
symbol reference.
It turns out weak versioned symbols still make the dynamic linker need
the symbol version, even if all symbols needed with that version are
weak.
Practically speaking, that means with bug 1634204, we now end up with
a weak versioned symbol reference to __cxa_thread_atexit_impl with
version GLIBC_2.18, and glibcs without the symbol can't fulfil that
version, even though the weak symbol is the only thing we need from that
version.
This means the check_binary changes in bug 1634204 are too
relaxed, so we revert them (although we keep the easier to read
conditions in check_dep_versions).
We also introduce a hack in stdc++compat.cpp (although it's not
technically entirely about libstdc++ compat) so that we avoid the weak
symbol reference while keeping the intended baseline for libstdc++ and
glibc.
Differential Revision: https://phabricator.services.mozilla.com/D79773
When linking a weak symbol in an object against a library where the
symbol is provided with a version, the final binary get a weak versioned
symbol reference.
It turns out weak versioned symbols still make the dynamic linker need
the symbol version, even if all symbols needed with that version are
weak.
Practically speaking, that means with bug 1634204, we now end up with
a weak versioned symbol reference to __cxa_thread_atexit_impl with
version GLIBC_2.18, and glibcs without the symbol can't fulfil that
version, even though the weak symbol is the only thing we need from that
version.
This means the check_binary changes in bug 1634204 are too
relaxed, so we revert them (although we keep the easier to read
conditions in check_dep_versions).
We also introduce a hack in stdc++compat.cpp (although it's not
technically entirely about libstdc++ compat) so that we avoid the weak
symbol reference while keeping the intended baseline for libstdc++ and
glibc.
Differential Revision: https://phabricator.services.mozilla.com/D79773
When linking a weak symbol in an object against a library where the
symbol is provided with a version, the final binary gets a weak versioned
symbol reference.
It turns out weak versioned symbols still make the dynamic linker need
the symbol version, even if all symbols needed with that version are
weak.
Practically speaking, that means with bug 1634204, we now end up with
a weak versioned symbol reference to __cxa_thread_atexit_impl with
version GLIBC_2.18, and glibcs without the symbol can't fulfil that
version, even though the weak symbol is the only thing we need from that
version.
This means the check_binary changes in bug 1634204 are too
relaxed, so we revert them (although we keep the easier to read
conditions in check_dep_versions).
We also introduce a hack in stdc++compat.cpp (although it's not
technically entirely about libstdc++ compat) so that we avoid the weak
symbol reference while keeping the intended baseline for libstdc++ and
glibc.
Differential Revision: https://phabricator.services.mozilla.com/D79773
In adcd026838, conversions from `StringRef` to `std::string` became `explicit`.
The NFC fix would be to wrap the conversions in `std::string(...)` but since these are all short-lived uses for things like string compares, I've refactored a bit to keep them in native form.
Differential Revision: https://phabricator.services.mozilla.com/D79895
Sometime during clang 11 (I don't have the exact commit handy), the display of nested templates changed from `Foo<Bar<X> >` to `Foo<Bar<X>>`.
Differential Revision: https://phabricator.services.mozilla.com/D79894
When linking a weak symbol in an object against a library where the
symbol is provided with a version, the final binary gets a weak versioned
symbol reference.
It turns out weak versioned symbols still make the dynamic linker need
the symbol version, even if all symbols needed with that version are
weak.
Practically speaking, that means with bug 1634204, we now end up with
a weak versioned symbol reference to __cxa_thread_atexit_impl with
version GLIBC_2.18, and glibcs without the symbol can't fulfil that
version, even though the weak symbol is the only thing we need from that
version.
This means the check_binary changes in bug 1634204 are too
relaxed, so we revert them (although we keep the easier to read
conditions in check_dep_versions).
We also introduce a hack in stdc++compat.cpp (although it's not
technically entirely about libstdc++ compat) so that we avoid the weak
symbol reference while keeping the intended baseline for libstdc++ and
glibc.
Differential Revision: https://phabricator.services.mozilla.com/D79773
I wrote this patch to address two problems:
1. if I do `mach run` from a directory other than $topsrcdir, $objdir, or
$objdir/dist/bin, then .gdbinit will not be loaded.
2. Debugging the firefox binary will never load the JS prettyprinters in any
case.
I believe this patch fixes other problems as well, such as .gdbinit_python not being found, and the gdbpp pretty-printers not getting loaded in various situations.
The main changes of this patch are:
1. Move .gdbinit into build/ (and $objdir/build/) to delay it from getting
loaded until the search path is configured.
2. Move libxul.so-gdb.py into the correct directory.
3. Use either libxul.so-gdb.py or js-gdb.py to configure the correct
search path then load .gdbinit, and have .gdbinit load all of the
pretty-printers (Gecko and JS).
4. Use a single preprocessed file to configure the source directory. Use
relative paths within the objdir for everything else.
Differential Revision: https://phabricator.services.mozilla.com/D77589
This brings the `android-build` image very close to other build
images, paving the way for it to be folded in completely. It also
makes us more resilient in the face of upstream service interruptions.
Differential Revision: https://phabricator.services.mozilla.com/D78945
I wrote this patch to address two problems:
1. if I do `mach run` from a directory other than $topsrcdir, $objdir, or
$objdir/dist/bin, then .gdbinit will not be loaded.
2. Debugging the firefox binary will never load the JS prettyprinters in any
case.
I believe this patch fixes other problems as well, such as .gdbinit_python not being found, and the gdbpp pretty-printers not getting loaded in various situations.
The main changes of this patch are:
1. Move .gdbinit into build/ (and $objdir/build/) to delay it from getting
loaded until the search path is configured.
2. Move libxul.so-gdb.py into the correct directory.
3. Use either libxul.so-gdb.py or js-gdb.py to configure the correct
search path then load .gdbinit, and have .gdbinit load all of the
pretty-printers (Gecko and JS).
4. Use a single preprocessed file to configure the source directory. Use
relative paths within the objdir for everything else.
Differential Revision: https://phabricator.services.mozilla.com/D77589
To avoid sending identifying information, common absolute paths are patched with placeholder values. For example, devs
may place their Firefox repository within their home dir, so absolute paths are doctored to be prefixed with
"<topsrcdir"> instead.
Additionally, any paths including the user's home directory are patched to instead be a relate path from "~".
Differential Revision: https://phabricator.services.mozilla.com/D78962
To avoid sending identifying information, common absolute paths are patched with placeholder values. For example, devs
may place their Firefox repository within their home dir, so absolute paths are doctored to be prefixed with
"<topsrcdir"> instead.
Additionally, any paths including the user's home directory are patched to instead be a relate path from "~".
Differential Revision: https://phabricator.services.mozilla.com/D78962
Rather than always printing instructions at the end of the bootstrap phase, we will now create a mozconfig
file if one doesn't exist and there's configuration to be written.
Differential Revision: https://phabricator.services.mozilla.com/D78417
For standalone JS builds there are three possibilities: no-NSPR (the default),
build NSPR, or use system NSPR.
This patch makes no-NSPR the default again when not overridden by --enable-nspr-build
or --with-system-nspr. This was likely regressed by bug 1641775.
Differential Revision: https://phabricator.services.mozilla.com/D78001
clang_getAddressSpace was found as a clang 5.0+ API by comparing the "tools/libclang/libclang.exports" files in the clang source code.
"clang_getAddressSpace" exists for 5.0.0 and 10.0.0, but not for 4.0.1.
Differential Revision: https://phabricator.services.mozilla.com/D78374
When not using --with-android-ndk, NDK root is `~/.mozbuild/android-ndk-r20`.
When building this NDK path, since we use `os.path.join`, so it may include "\"
as file separator on Windows host. Then some options such as `-gcc-toolchain`
become invalid path (ex. `C:/users/makoto.mozbuildandroid-ndk-r20/`..).
So we should replace file separator with "/".
Differential Revision: https://phabricator.services.mozilla.com/D77820
When running |mach python| with python 3, it was failing when importing "enum", since it would get the python 2 backport. By making these packages only
available to python 2, we allow python 3 to import standard library packages properly.
Differential Revision: https://phabricator.services.mozilla.com/D77960
Version of NSS >= 3.27 have a pkg-config file. We're now requiring 3.53,
so while moving, just use pkg-config, which is simpler.
The old-configure check that rejected some untested platforms for
in-tree NSS is actually rejecting none: the accepted platforms cover all
the supported ones, so we remove that check.
And because building with system NSS without system NSPR doesn't make
sense, imply the latter when the former is used.
Differential Revision: https://phabricator.services.mozilla.com/D77428
At the same time, because it's now simpler to do so, set the right data
file name for big-endians, even though we don't have or produce it
(bug #1264836). Also remove USE_ICU, which is redundant with
JS_HAS_INTL_API, and actively break the build at configure time when
using --without-intl-api with Firefox because this hasn't actually
worked for close to 3 years (since bug 1402048).
Differential Revision: https://phabricator.services.mozilla.com/D77416
Versions of NSPR >= 4.10 come with a pkg-config file. We currently
depend on 4.9.2 for spidermonkey, but much more recent versions for
Firefox. 4.10 is less than a year newer than 4.9.2, and 4.10 is 7 years
old, so bumping the requirement to 4.10 is not really a big deal.
With the use of pkg-config, --with-nspr-cflags and --with-nspr-libs are
not needed.
None of the AC_TRY_COMPILE tests were any useful because
PR_STATIC_ASSERT and PR_UINT64 have been when we look for them since
4.8.6 and 4.9 respectively.
Differential Revision: https://phabricator.services.mozilla.com/D77412
As all versions of zlib >= 1.2.3.1 have a pkg-config file, and 1.2.3.1
is close to 14 years old, let's drop 1.2.3 and just use pkg-config, which
simplifies what we need to do dramatically.
Differential Revision: https://phabricator.services.mozilla.com/D77404
l10n-merge creates a full merge dir for a while now, let's
simplify the build logic to only read from that directory
during repacks and langpacks.
Differential Revision: https://phabricator.services.mozilla.com/D77023
Instead of doing this:
a) read existing file into memory
b) append new entries
c) sort all entries
d) write unique entries back to file
We now do this:
a) sort new entries
b) loop through existing file entries, one at a time, writing them to a tmp file
c) insert the new entries in between the existing file entries in lexicographic order,
and deduplicating the new entries
d) write any remaining new entries (that are lexicographically after the last
entry in the pre-existing file), again deduplicating the entries
e) move tmp file back to original file location
This avoids reading the entire file into memory which could be potentially
hundreds of MB large.
The changes in FileOperations.* are needed to support these changes, as we now
have two files that we're dealing with - reading from one and writing to the
other. We still use a Mutex (Windows) or exclusive-flock (POSIX) on the file
for the duration of the entire operation, so we should still be robust in the
face of multiple concurrently running clang processes.
Differential Revision: https://phabricator.services.mozilla.com/D76202
The configure sandbox has a list of arguments to handle, and removes
each of them when it resolves the corresponding options through e.g. a
`@depends`. When the configure sandbox is finished, what's supposed to
be left is unknown options.
The mozconfig injections adds elements to that list of arguments to
handle. The problem is that by the time the mozconfig injection happens,
some early options have already been handled by the sandbox and won't be
re-handled. Which means by the end of configure, the arguments are still
there, and the sandbox throws an error because it thinks they are for
unknown options.
Things were actually working before bug 1264527, essentially because we
had an explicit list of mozconfig variables that would be injected, and
that didn't include those early options.
So what we now do is to not actually inject those early options from
mozconfig.
Differential Revision: https://phabricator.services.mozilla.com/D76276
The expanded checks in clang 10 made arm64 builds hit CFG crashes on nsXPTCStubBase vtables on startup.
It's not clear why this doesn't happen on x86 builds. Given our current level of support for arm64, I can't really justify investigating this, although I suspect that fixing the underlying issue would be pretty much bug 1483885.
As a get-unblocked stopgap, `-guard:cf,nochecks` in clang 10 gives the same behavior as `-guard:cf` in clang 9.
Differential Revision: https://phabricator.services.mozilla.com/D76216
The "clang-9" variant of the patch is no longer present. For clang-7, the patch
file to use is now "find_symbolizer_linux.patch".
Differential Revision: https://phabricator.services.mozilla.com/D76176
Configuration values defined above `mozconfig_options` in `init.configure` are those that can't be configured in `mozconfig`. As far as I can tell there is nothing wrong *in principle* with setting `PYTHON3` in `mozconfig`, so here we just bump `mozconfig_options` above `PYTHON3` configuration.
Side note, diagnosing this failure took a *long* time. The error message that this produced ("unknown option `PYTHON3`") is useless and the underlying algos being extremely mutable, I ended up having to spend a lot of time in the debugger and monitor all the underlying changes to a bunch of mutable data structures to determine where `PYTHON3` was getting lost. A better error message would be good here but I don't know how I would begin adding it.
Differential Revision: https://phabricator.services.mozilla.com/D75635
--enable-hardware-aec-ns option does nothing so it is deleted too.
removed `hardware_aec_ns` from gyp vars since it is never used
Differential Revision: https://phabricator.services.mozilla.com/D75798
Create a new MachCommandCondition, "is_firefox_or_thunderbird" which is then used
to allow mach valgrind-test work for Thunderbird builds.
Differential Revision: https://phabricator.services.mozilla.com/D73153
iOS support for Gecko has not been tested in years and is most probably
out of date. The build system part of it, specifically the checks in
build/autoconf/ios.m4, are not trivial to port to python configure, and
they prevent other things from moving to python configure (because some
of them change value when MOZ_IOS is set).
The code is left alone, although it could probably be stripped off as
well, but I'll leave that as an exercise for someone else.
Differential Revision: https://phabricator.services.mozilla.com/D75463
If we don't do this, configure will happily think the linker kind is
"unknown", which then causes problems downstream.
Differential Revision: https://phabricator.services.mozilla.com/D75300
This patch is adding an option to push a perftest run in the CI.
It's based on :
- sparse profiles
- push_to_try
- options passed through try_task_config.json
Differential Revision: https://phabricator.services.mozilla.com/D74115
ubsan's generated code trips an optimization corner case in clang 10. This is a short-term workaround. In the best case, llvm.org/pr45835 will land a fix soon, and we can merge that for our clang-10 update and not even land this patch. However, in case we're living in anything other than the best case world, I don't want to block on that happening.
Differential Revision: https://phabricator.services.mozilla.com/D74727
ubsan's generated code trips an optimization corner case in clang 10. This is a short-term workaround. In the best case, llvm.org/pr45835 will land a fix soon, and we can merge that for our clang-10 update and not even land this patch. However, in case we're living in anything other than the best case world, I don't want to block on that happening.
Differential Revision: https://phabricator.services.mozilla.com/D74727
