CLOSED TREE
Backed out changeset 01548614184b (bug 1602773)
Backed out changeset 430c8e6b0c5a (bug 1602773)
Backed out changeset 1b4e2b044fcd (bug 1602773)
- Remove the separate option() for MT, because it dates back from when
we needed `MT` not being an absolute path, but that hasn't been true
since bug 1290040.
- Extend what was done in bug 1617794 to MT, although the long term move
is to not rely on MT at all.
- Patch leftovers from bug 1613799.
Differential Revision: https://phabricator.services.mozilla.com/D64712
--HG--
extra : moz-landing-system : lando
One part is fixing old-configure.in to use `pwd` when `pwd -W` doesn't work
(it errors on Linux), and another part is supporting two additional
system calls in liblowercase:
- chdir used in the same commands as the `pwd -W` fix
- symlink, used by the install manifest processor to create symbolic
links of those DLLs in $MOZ_OBJDIR/dist/bin.
Differential Revision: https://phabricator.services.mozilla.com/D64707
--HG--
extra : moz-landing-system : lando
This is to fix build bustage until Thunderbird engineers are able to migrate
these threads to use background tasks.
Differential Revision: https://phabricator.services.mozilla.com/D64795
--HG--
extra : moz-landing-system : lando
Creates a NoNewThreadsChecker plugin that looks for the function and checks to see if it's allowed.
-Creates two allowlists - `ThreadAllows.txt` is for thread names, while `ThreadFileAllows.txt` checks for entire files where instances of `NS_NewNamedThread` should be ignored.
-If an instance of `NS_NewNamedThread` is not listed in either list, then the checker throws an error with an additional note containing a more descriptive explanation of the failure.
Differential Revision: https://phabricator.services.mozilla.com/D62635
--HG--
extra : moz-landing-system : lando
WebAuthn needs to write a test to confirm it's prohibited when accessed via
an IP address. This adds the capability to get a SecureContext for an IP host.
It uses 127.0.0.2 so as to bypass restrictions on 127.0.0.1, and the use of .1
as a special-market in ssltunnel.
Differential Revision: https://phabricator.services.mozilla.com/D63570
--HG--
extra : moz-landing-system : lando
Depending on the target, the assembler for Windows builds is one of ml,
ml64, or armasm64. Only for the latter currently are we looking for the
assembler with the .exe extension. All of them should be looked for the
same way, and we pick including the extension.
Differential Revision: https://phabricator.services.mozilla.com/D64260
--HG--
extra : moz-landing-system : lando
We're feeding old-configure with compiler and assembler as found by
python configure via ac_cv_* variables (abusing the autoconf cache).
When doing so, and when the assembler was provided via an environment
variable, while python configure resolves the path, old-configure
doesn't get the resolved path, because we're currently passing it the
path that was passed via the environment.
Now pass the resolved path instead.
Differential Revision: https://phabricator.services.mozilla.com/D64258
--HG--
extra : moz-landing-system : lando
We don't need to package tests for builds that we don't actually run
tests from, but it is tricky to align this correctly by setting
MOZ_AUTOMATION_PACKAGE_TESTS=0 in relevant mozconfigs. Instead we can
set the environment variable in the task definition, and use a full
taskgraph verification check to ensure that the flag is only set on
builds that have tests.
The one tricky area is the win64-aarch64 builds, which have a workaround
by specifying the new skip-verify-test-packaging attribute.
In one case, win64-aarch64-shippable has tests that run against it, but
it copies those tests from a win64-aarch64-shippable-no-eme task, which
itself has no tests. Both of those tasks need to skip the verify check
as a result.
In another case, the win64-aarch64-eme task is an artifact build that
grabs test packages from the win64-aarch64 build. Since the win64-aarch64
build doesn't have tests, it needs to skip the verify check.
Differential Revision: https://phabricator.services.mozilla.com/D59426
--HG--
extra : moz-landing-system : lando
We don't need to package tests for builds that we don't actually run
tests from, but it is tricky to align this correctly by setting
MOZ_AUTOMATION_PACKAGE_TESTS=0 in relevant mozconfigs. Instead we can
set the environment variable in the task definition, and use a full
taskgraph verification check to ensure that the flag is only set on
builds that have tests.
The one tricky area is the win64-aarch64 builds, which have a workaround
by specifying the new skip-verify-test-packaging attribute.
In one case, win64-aarch64-shippable has tests that run against it, but
it copies those tests from a win64-aarch64-shippable-no-eme task, which
itself has no tests. Both of those tasks need to skip the verify check
as a result.
In another case, the win64-aarch64-eme task is an artifact build that
grabs test packages from the win64-aarch64 build. Since the win64-aarch64
build doesn't have tests, it needs to skip the verify check.
Differential Revision: https://phabricator.services.mozilla.com/D59426
--HG--
extra : moz-landing-system : lando
Creates a NoNewThreadsChecker plugin that looks for the function and checks to see if it's allowed.
-Creates two allowlists - `ThreadAllows.txt` is for thread names, while `ThreadFileAllows.txt` checks for entire files where instances of `NS_NewNamedThread` should be ignored.
-If an instance of `NS_NewNamedThread` is not listed in either list, then the checker throws an error with an additional note containing a more descriptive explanation of the failure.
Differential Revision: https://phabricator.services.mozilla.com/D62635
--HG--
extra : moz-landing-system : lando
This patch will support all of `-std:`, `-std=`, and `-Xclang -std=`.
This patch will also a bit faster because the current code will call `sed` for
each argument.
Differential Revision: https://phabricator.services.mozilla.com/D63472
--HG--
extra : moz-landing-system : lando
Install moz-phab using the correct command for the current operating system as
per moz-phab's documentation.
Differential Revision: https://phabricator.services.mozilla.com/D59139
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
Best as I can tell, this was a longstanding typo. This went unnoticed because cmake didn't do any interesting `find`s -- until recently in LLVM 10, where zlib is now queried via `find_package`.
Differential Revision: https://phabricator.services.mozilla.com/D62829
--HG--
extra : moz-landing-system : lando
While this works on Windows, because os.pathsep is `;`, it actually
doesn't work on non-Windows, because clang-cl is still expecting `;`,
but os.pathsep is `:`.
Differential Revision: https://phabricator.services.mozilla.com/D62862
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
clang-plugin.dll links against clang.exe so they both need to use the same C++ standard. This is achieved by having build/clang-plugin/moz.build use the flags from llvm-config. However, llvm-config uses the `-std:c++14` format, so our flags end up looking like:
`-Xclang -std=c++17 ... -std:c++14`
and apparently the former wins out in clang's option plumbing, so the compiler still thinks we requested c++17.
This patch makes clang-plugin use the `-Xclang -std=` format so that the override happens as desired.
Differential Revision: https://phabricator.services.mozilla.com/D62271
--HG--
extra : moz-landing-system : lando
This ensures that we don't pass non-trivially-copiable types through the FFI
boundary.
Differential Revision: https://phabricator.services.mozilla.com/D61626
--HG--
extra : moz-landing-system : lando
After a C++ language version bump, It's possible to wind up in
situations where we are using a new enough compiler version, but the
libstdc++ version in use is not new enough to support new language
features: self-compiled clang with system libraries, clang from `mach
bootstrap` prior to C++ language version bump (and thus including a new
libstdc++ with the boostrapped clang), etc.
Previously, such a situation would mean that things would work fine, and
then start breaking as soon as new library features started to be used.
Let's try to catch the problem earlier, when the update happens, by
verifying that the libstdc++ version is at least as new as the GCC
version we're requiring.
Differential Revision: https://phabricator.services.mozilla.com/D57516
--HG--
extra : moz-landing-system : lando
I need this to support individual #[cfg] in enum variants, which is used for
Image::PaintWorklet.
Differential Revision: https://phabricator.services.mozilla.com/D62160
--HG--
extra : moz-landing-system : lando
This is a re-work of `https://mzl.la/31Bkl47`, and because time passed and not all of the
issues reported by this checker were fixed and we want to land it, we've decided to move
from errors diagnostic messages to warnings.
Differential Revision: https://phabricator.services.mozilla.com/D61753
--HG--
extra : moz-landing-system : lando
Stop using mozcrash.check_for_java_exception(), which scans logcat for uncaught
exceptions. Instead, check for java_stack in the extra dump information during
normal crash reporting; if java_stack is present, display the java exception and
stack instead of dumping a full native crash report.
Differential Revision: https://phabricator.services.mozilla.com/D61836
--HG--
extra : moz-landing-system : lando
fts.h is also missing on musl. Since the Solaris fallback implementation
does not use any non-standard functions, use that as the fallback when
the FTS interface is not available.
Also, fix an issue with the readdir implementation. Previously, the
absolute directory path was passed to the recursive add_dir_entries()
call, which would then prepend install path again.
Differential Revision: https://phabricator.services.mozilla.com/D61407
--HG--
extra : moz-landing-system : lando
The logic for finding the sccache configuration to use has gone through several
iterations. At this point, all the build workers set
`TASKCLUSTER_WORKER_LOCATION`, so remove the code for dealing with other
configurations. Also don't set sccache configuration if it is disabled, even
if the bucket somehow gets set.
Differential Revision: https://phabricator.services.mozilla.com/D61635
--HG--
extra : moz-landing-system : lando
The code goes to some length to calculate the bucket to use, but then
hard-codes the bucket in the credential URL it uses.
Differential Revision: https://phabricator.services.mozilla.com/D61634
--HG--
extra : moz-landing-system : lando
Starting with `Clang-10`, and in particular with `https://reviews.llvm.org/D66404`,
the `CFG` has been reflown in order to reduce discrepancies in destructor calls with
the actual codegen. This has also impacted the order of `CFGStmt` for `ReturnStmt`,
whereas now the AST children of the `ReturnStmt` have precedence other their parent
node.
The purpose of this patch is to fix this and add new supported cases for the `Expr`
that is generated from `ReturnStmt`.
Differential Revision: https://phabricator.services.mozilla.com/D61556
--HG--
extra : moz-landing-system : lando
JSAPI functions are not extern "C" anymore. This warning has a couple false
positives due to template specialization (see first patch of this bug), but we
were already working around them, because apparently some mingw builds use it.
Once I fix cbindgen to generate the specializations as needed we can remove
those workarounds, but this is green in the meantime and doesn't hurt.
Depends on D61626
Differential Revision: https://phabricator.services.mozilla.com/D61627
--HG--
extra : moz-landing-system : lando
Much of Firefox's mozocnfig.cache file is duplicated in Thunderbird's tree
in order to set a slightly different bucket name. This has led to broken buids
in the past.
The only difference is the first part of the name. With this change, a Thunderbird
mozconfig file can set $aws_prefix to "comm-central" before mozconfig.cache
gets included and be correctly configured.
GCP support is not required at this time.
Differential Revision: https://phabricator.services.mozilla.com/D61143
--HG--
extra : moz-landing-system : lando
Adding --no-insert-timestamp to APPEND_LINKFLAGS for nsis is not working as it
is used for both the host and cross-compiled parts, but this option is
only valid for the Windows linker. Therefore we add it using a patch
to the cross-compilation part only.
Differential Revision: https://phabricator.services.mozilla.com/D61321
--HG--
extra : moz-landing-system : lando
v0.12.2 at least is needed to have proper v2 lockfile support.
But v0.13.0 contains extra fixes, and features that wgpu and the style system
plan to use, so let's just update to that.
Differential Revision: https://phabricator.services.mozilla.com/D61334
--HG--
extra : moz-landing-system : lando
This disables the l10n-check as part of the build, now that we have
on-push L10n jobs.
Differential Revision: https://phabricator.services.mozilla.com/D60722
--HG--
extra : moz-landing-system : lando
It generates a lot of noise and we don't want to fix them. In particular, all
the cycle collector macros are like this.
Differential Revision: https://phabricator.services.mozilla.com/D59646
--HG--
extra : moz-landing-system : lando
This is an alternative to carrying a revert of the offending changeset, since the bug doesn't show hope of a fix anytime soon, or maybe ever. This way we don't have to keep rebasing the patch as we pick up new clangs, and developers don't have to remember to apply the patch when building a local compiler.
Differential Revision: https://phabricator.services.mozilla.com/D59200
--HG--
extra : moz-landing-system : lando
This gets rid of the last use of the 'which' module left in the tree. So not
only will this help 'configure' become a little more Python 3 compatible, but
we can now remove 'third_party/python/which'.
Differential Revision: https://phabricator.services.mozilla.com/D37427
--HG--
extra : moz-landing-system : lando
We don't need to package tests for builds that we don't actually run
tests from, but it is tricky to align this correctly by setting
MOZ_AUTOMATION_PACKAGE_TESTS=0 in relevant mozconfigs. Instead we can
set the environment variable in the task definition, and use a full
taskgraph verification check to ensure that the flag is only set on
builds that have tests.
The one tricky task is win64-aarch64-shippable/opt, which copies tests
from another build rather than building them itself. For this reason, it
explicitly sets MOZ_AUTOMATION_PACKAGE_TESTS: '0' in the environment
even though that is now the default. This is why the exception is only
raised if MOZ_AUTOMATION_PACKAGE_TESTS is not set at all, rather than
checking that it is set to 1.
Differential Revision: https://phabricator.services.mozilla.com/D59426
--HG--
extra : moz-landing-system : lando
Otherwise we won't package the necessary libraries, which leads to
peculiar runtime failures.
Depends on D59555
Differential Revision: https://phabricator.services.mozilla.com/D59556
--HG--
extra : moz-landing-system : lando
This gets rid of the last use of the 'which' module left in the tree. So not
only will this help 'configure' become a little more Python 3 compatible, but
we can now remove 'third_party/python/which'.
Differential Revision: https://phabricator.services.mozilla.com/D37427
--HG--
extra : moz-landing-system : lando
This patch is not ideal: if would be better to do the defaulting in
`toolkit/moz.configure`, but doing it there runs into problems with base
toolchain configurations, as the clang there is not new enough. So we
have this, doing everything with environment variables, which is easily
turned on or off, depending on the needs of the specific configuration.
The `mozconfig.no-compile` change is not really needed, as the wasm
sandboxing detection bits are not conditional on
`--enable-compile-environment`. Those bits should be, and I will tackle
doing that after the holidays.
Differential Revision: https://phabricator.services.mozilla.com/D58102
--HG--
extra : moz-landing-system : lando
The purpose of this patch is to add support for `if constexpr` statements for the above checkers.
`readability-braces-around-statements` fix has been back-ported from <https://reviews.llvm.org/D71980>
and the fix for `readability-misleading-indentation` uses the same logic as a principle.
Differential Revision: https://phabricator.services.mozilla.com/D58825
--HG--
extra : moz-landing-system : lando
This patch is not ideal: if would be better to do the defaulting in
`toolkit/moz.configure`, but doing it there runs into problems with base
toolchain configurations, as the clang there is not new enough. So we
have this, doing everything with environment variables, which is easily
turned on or off, depending on the needs of the specific configuration.
The `mozconfig.no-compile` change is not really needed, as the wasm
sandboxing detection bits are not conditional on
`--enable-compile-environment`. Those bits should be, and I will tackle
doing that after the holidays.
Differential Revision: https://phabricator.services.mozilla.com/D58102
--HG--
extra : moz-landing-system : lando
