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
MessagePool brings no benefit over the traditional nsIThread.
Additonally, replace some incorrect use of RefPtr for xpcom objects.
Differential Revision: https://phabricator.services.mozilla.com/D73827
MessagePool brings no benefit over the traditional nsIThread.
Additonally, replace some incorrect use of RefPtr for xpcom objects.
Differential Revision: https://phabricator.services.mozilla.com/D73827
Without this, taskgraph calculates the digest based on just the files in these
directories that are in the sparse profile (I suspect this is just the
moz.build files), and will rebuild it when those files change. This changes
ensures that all files in those directories are used to calculate the digest.
Additionally, this will cause the same digest to be generted by developers
locally, since the files *are* present in the non-sparse checkout that most
developers have.
Differential Revision: https://phabricator.services.mozilla.com/D74113
Extends the desktop changes made in bug 1475141 to Android, to avoid confusion when the
browser hangs between tests, or during shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D74284
We do this to avoid unnecessarily penalizing subprocess invocations from
within mach (and all child processes) on some Linux setups.
Differential Revision: https://phabricator.services.mozilla.com/D66786
As of bug 1621451 this argument was ignored, but it just silently runs your code with `python3` if you pass it anyway. Ensure this doesn't happen any more, and protect against any other unexpected arguments as well.
Differential Revision: https://phabricator.services.mozilla.com/D73485
The license used to be LGPL so the code lived in other-licenses, but it was changed to BSD eleven years ago. Let's move it over to third_party/python/ply where it belongs.
./mach vendor python ply==3.10
`diff -r` between the original `ply` directory and the new one only comes up with the new file `third_party/python/ply/CHANGES` which isn't relevant to the functionality of the code, so this should be a no-op all told.
Differential Revision: https://phabricator.services.mozilla.com/D73341
We do this to avoid unnecessarily penalizing subprocess invocations from
within mach (and all child processes) on some Linux setups.
Differential Revision: https://phabricator.services.mozilla.com/D66786
MessagePool brings no benefit over the traditional nsIThread.
Additonally, replace some incorrect use of RefPtr for xpcom objects.
Differential Revision: https://phabricator.services.mozilla.com/D73827
This gets rid for the need of a number of local packages (mostly related
to Gtk+3). One exception is that we now need a 32-bits version of the
xz-utils package, some -dev package depends on it, and that dependency
can't be fulfilled in the 32-bits image because we already have the
64-bits backport installed, which conflicts with it (we need both
32-bits and 64-bits package to be at the same version when installed).
The system binutils fails to link clang-7 for some reason, so we now use
our toolchain binutils instead, like we already do for newer versions of
clang.
The debian-packages docker image now needs an explicit installation of
git, because it's not pulled in via the recommends of some other
package.
For some reason, snapshot.debian.org doesn't contain the jessie-backports
archive at the same location as others, and only has a few snapshots of
the archive.
Differential Revision: https://phabricator.services.mozilla.com/D73784
Now that upstream winchecksec builds and works natively on Linux, use
that. That should solve the random crashes under Wine. If random crashes
still happen, it will be easier to debug anyways.
We bump to the last version that doesn't use vcpkg because vcpkg makes
things more difficult.
Differential Revision: https://phabricator.services.mozilla.com/D73405
This removes processing of HTTP Public Key Pinning headers, remotely modifying
pinning information, and using cached pinning information, all of which was
already disabled in bug 1412438. Static pins that ship with the browser are
still enforced.
Differential Revision: https://phabricator.services.mozilla.com/D73352
This gets rid for the need of a number of local packages (mostly related
to Gtk+3). One exception is that we now need a 32-bits version of the
xz-utils package, some -dev package depends on it, and that dependency
can't be fulfilled in the 32-bits image because we already have the
64-bits backport installed, which conflicts with it (we need both
32-bits and 64-bits package to be at the same version when installed).
The system binutils fails to link clang-7 for some reason, so we now use
our toolchain binutils instead, like we already do for newer versions of
clang.
The debian-packages docker image now needs an explicit installation of
git, because it's not pulled in via the recommends of some other
package.
For some reason, snapshot.debian.org doesn't contain the jessie-backports
archive at the same location as others, and only has a few snapshots of
the archive.
Differential Revision: https://phabricator.services.mozilla.com/D73784
This gets rid for the need of a number of local packages (mostly related
to Gtk+3). One exception is that we now need a 32-bits version of the
xz-utils package, some -dev package depends on it, and that dependency
can't be fulfilled in the 32-bits image because we already have the
64-bits backport installed, which conflicts with it (we need both
32-bits and 64-bits package to be at the same version when installed).
The system binutils fails to link clang-7 for some reason, so we now use
our toolchain binutils instead, like we already do for newer versions of
clang.
The debian-packages docker image now needs an explicit installation of
git, because it's not pulled in via the recommends of some other
package.
For some reason, snapshot.debian.org doesn't contain the jessie-backports
archive at the same location as others, and only has a few snapshots of
the archive.
Differential Revision: https://phabricator.services.mozilla.com/D73784
This gets rid for the need of a number of local packages (mostly related
to Gtk+3). One exception is that we now need a 32-bits version of the
xz-utils package, some -dev package depends on it, and that dependency
can't be fulfilled in the 32-bits image because we already have the
64-bits backport installed, which conflicts with it (we need both
32-bits and 64-bits package to be at the same version when installed).
The system binutils fails to link clang-7 for some reason, so we now use
our toolchain binutils instead, like we already do for newer versions of
clang.
The debian-packages docker image now needs an explicit installation of
git, because it's not pulled in via the recommends of some other
package.
For some reason, snapshot.debian.org doesn't contain the jessie-backports
archive at the same location as others, and only has a few snapshots of
the archive.
Differential Revision: https://phabricator.services.mozilla.com/D73784
This includes scripts that involve `tup`, jobs that build `tup` in automation, `tup.configure`, and related infrastructure and documentation.
Differential Revision: https://phabricator.services.mozilla.com/D73921
Now that there are only two uses of it, and there won't be more, remove
them and just use host_for_sub_configure and target_for_sub_configure
directly.
Differential Revision: https://phabricator.services.mozilla.com/D73411
As mentioned in previous change, js subconfigure used to be called from
old-configure, and some of that old setup remains to this day.
They don't really cause problems, except speed issues, especially on
Windows: arguments passed to old-configure is treated in a large shell
loop, and the more arguments are passed, the longer it takes. On my
machine, this cumulates to more than 10s! For arguments it doesn't
recognizes and doesn't use. And the environment variable js_options are
not used either, although they don't have a similar impact.
What we're doing here:
- Remove js_options from extra_old_configure_args, that leaves only
host_for_sub_configure and target_for_sub_configure there.
- Since none of the above are environment variables, we don't need to
separate out environment variables, nor to pass them down to
old-configure.
Differential Revision: https://phabricator.services.mozilla.com/D73410
js subconfigure used to be invoked from old-configure, and the
transition out of old-configure preserved the code sharing.
prepare_configure_options currently collects all the old configure
arguments, separating js_option arguments from js_option environment
variables. This distinction is necessary for old configure, but not
for python configure, so we can now handle all the js_options
similarly.
Differential Revision: https://phabricator.services.mozilla.com/D73409
Add the -X switch to ignore default include path, and tolerate proprocessor failures.
This enables the check to skip a directory that is missing headers, instead of
falling back on the default paths.
Differential Revision: https://phabricator.services.mozilla.com/D73371
Now that upstream winchecksec builds and works natively on Linux, use
that. That should solve the random crashes under Wine. If random crashes
still happen, it will be easier to debug anyways.
We bump to the last version that doesn't use vcpkg because vcpkg makes
things more difficult.
Differential Revision: https://phabricator.services.mozilla.com/D73405
Currently MozillaBuild with $PYTHON3 first creates virtualenv with the path from environment variable and then reexecutes with its own bundled executable. This patch forces it to run with virtualenv python when reexecuting.
Differential Revision: https://phabricator.services.mozilla.com/D72446