As of clang 8, llvm-config doesn't return all flags clang was built
with, and omits some flags that do impact the libclang ABI,
-stdlib=libc++ being one of them (it might well be the only one).
Building clang with LLVM_ENABLE_LIBCXX=ON does build it with
-stdlib=libc++, but is unrelated to whether or not libc++ is built and
shipped with clang, which still happens without it.
So while versions older than clang 8 are not really affected, it doesn't
hurt to build clang without -stdlib=libc++ (especially when it
currently only applies to the clang used to cross build android with
PGO, not even the other android cross builds), in preparation for
switching to clang 8.
Differential Revision: https://phabricator.services.mozilla.com/D25031
--HG--
extra : moz-landing-system : lando
There is no concern that the Android NDK clang may not support it, as
the flag was added in clang 2.9. The flag is also not supported with
GCC, which is not ideal, but we already crossed that bridge at least
with -gcc-toolchain added in extra_toolchain_flags, which is not
supported by GCC either.
Differential Revision: https://phabricator.services.mozilla.com/D25019
--HG--
extra : moz-landing-system : lando
We shouldn't pass those flags when building C. It doesn't matter /too/
much currently, but will in a subsequent change, which will introduce
a C++-only flag in stlport_cppflags.
Differential Revision: https://phabricator.services.mozilla.com/D25018
--HG--
extra : moz-landing-system : lando
Other than the MediaPipelineFactory references, nothing else is obsolete, so this is a
very minor cleanup, just to improve readability a bit.
Differential Revision: https://phabricator.services.mozilla.com/D25124
--HG--
extra : moz-landing-system : lando
Last time we updated the requirements was in bug 1278456, after we
switched to GTK+3.
While it might be worth checking what would be a reasonable requirement,
the immediate problem is that updating ANGLE hits a snag with a
libstdc++ 4.7 symbol, and the only main distro release that bumping to
that version would make us not support anymore is Ubuntu 12.04 LTS,
EOLed 2 years ago (April 2017).
Bumping to some even newer version would need more consideration.
Desupporting Ubuntu 12.04 LTS at this point is almost a no-brainer.
Differential Revision: https://phabricator.services.mozilla.com/D23979
--HG--
extra : moz-landing-system : lando
We need to have full symbols uploaded for the upcoming EME-enabled
win64-aarch64 nightlies, and the tasks to do that are derived from the
nightly itself, which is going to be an artifact build. Bug 1527463 took
care of adding the option to enable that, and we turn it on for
EME-enabled builds.
MOZ_ARTIFACT_TASK_WIN32_OPT is not exactly the right thing, but we're
already using it to enable EME in
browser/config/mozconfigs/win64-aarch64/common-opt and is only set on
those builds.
Differential Revision: https://phabricator.services.mozilla.com/D23639
When installing JDK 1.8, it writes path to the following registry.
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit\1.8\JavaHome
So we use this registry to detect JDK installation path on Windows if available.
Differential Revision: https://phabricator.services.mozilla.com/D20449
--HG--
extra : rebase_source : d8a380d9839f4de749815f3c81665e8d00226862
The current setup uses different ways for different platforms, with
different workarounds, even using extra configuration items for Windows.
Now that there can't be a difference between the host per the build
system and the host per rust, we can get rid of those configuration
items, and use a more common infrastructure.
We cannot, however, avoid using wrapper scripts, because per-target rust
link-arg flags don't work up great.
The downside is that multiplies the number of wrappers, as we now have
to have a different one for host and target, and then we have .bat files
and shell scripts for, respectively, Windows hosts, and other hosts.
Depends on D24321
Differential Revision: https://phabricator.services.mozilla.com/D24322
--HG--
extra : moz-landing-system : lando
While the substitution pattern is kind of awful in make, it will allow
to more straightforwardly deal with the difference between target and
host.
Differential Revision: https://phabricator.services.mozilla.com/D24321
--HG--
extra : moz-landing-system : lando
The current setup uses different ways for different platforms, with
different workarounds, even using extra configuration items for Windows.
Now that there can't be a difference between the host per the build
system and the host per rust, we can get rid of those configuration
items, and use a more common infrastructure.
We cannot, however, avoid using wrapper scripts, because per-target rust
link-arg flags don't work up great.
The downside is that multiplies the number of wrappers, as we now have
to have a different one for host and target, and then we have .bat files
and shell scripts for, respectively, Windows hosts, and other hosts.
Depends on D24321
Differential Revision: https://phabricator.services.mozilla.com/D24322
--HG--
extra : moz-landing-system : lando
While the substitution pattern is kind of awful in make, it will allow
to more straightforwardly deal with the difference between target and
host.
Differential Revision: https://phabricator.services.mozilla.com/D24321
--HG--
extra : moz-landing-system : lando
Newer versions of rust come with a specialized arm target that matches
more closely our armv7 targets (with neon and thumb2), so use that when
possible.
Depends on D24324
Differential Revision: https://phabricator.services.mozilla.com/D24325
--HG--
extra : moz-landing-system : lando
Some of our builds use --enable-warnings-as-errors and some don't, and I can't
figure out a way to write an expectation comment for that.
Differential Revision: https://phabricator.services.mozilla.com/D24469
--HG--
extra : moz-landing-system : lando
MT is part of the Windows SDK, not MSVC, but an alternative exists for
it: llvm-mt. The official LLVM distribution for Windows doesn't include
it[1], though, so we can't just switch to it.
1. https://bugs.llvm.org/show_bug.cgi?id=40152
While here, remove the .exe suffix from the check, to future-proof for
cross-windows builds.
Differential Revision: https://phabricator.services.mozilla.com/D24326
--HG--
extra : moz-landing-system : lando
The definitions can't be entirely removed yet because NSS still needs them.
Differential Revision: https://phabricator.services.mozilla.com/D23454
--HG--
extra : moz-landing-system : lando
Since these are compile-time constants, they can't exactly go away on us due to
running script, right?
Differential Revision: https://phabricator.services.mozilla.com/D24195
--HG--
extra : moz-landing-system : lando
We need to typecheck the trivials too, not just the final thing after trivials
are stripped, because casts are trivials.
Differential Revision: https://phabricator.services.mozilla.com/D24186
--HG--
extra : moz-landing-system : lando
The old code for member method calls did the following:
1) Find the member method calls.
2) Look at their "this" expression.
3) If the "this" is an operator call, check for any of the arguments of the
operator call being invalid.
4) Otherwise (if not an operator call) check for the "this" value being
invalid.
This wasn't right, because the "is invalid" check checks the type and only
considers refcounted things. So if the code looked something like
"foo[i]->call_method()", we would look at the types of "foo" and "i" and
determine that none of those are refcounted types so there is nothing invalid
here (since "foo" is some sort of array type and "i" is an integer). The new
setup just checks whether the "this" value is invalid, which does the type
check on the "this" value itself; in the "foo[i]->call_method()" case on
"foo[i]". We then adjust the exclusions in InvalidArg to consider operator->
on known-live things valid, to allow the thing that we were really trying to
accomplish with the "check for an operator call" bits:
"stackRefPtr->some_method()".
The test coverage being added for the made-up TArray type is meant to catch
things like the geolocation issue that was being hidden by the buggy behavior.
I'm not using nsTArray itself because some header included by nsTArray.h
tries to define operator new/delete bits inline and that triggers warnings that
then cause a clang-plugin test failure, because they're unexpected.
Differential Revision: https://phabricator.services.mozilla.com/D24117
--HG--
extra : moz-landing-system : lando
"this" is guaranteed to stay alive as long as other MOZ_CAN_RUN_SCRIPT
conditions hold, and its const members can't change value and drop
their refs.
Differential Revision: https://phabricator.services.mozilla.com/D23997
--HG--
extra : moz-landing-system : lando
We need to have full symbols uploaded for the upcoming EME-enabled
win64-aarch64 nightlies, and the tasks to do that are derived from the
nightly itself, which is going to be an artifact build. Bug 1527463 took
care of adding the option to enable that, and we turn it on for
EME-enabled builds.
MOZ_ARTIFACT_TASK_WIN32_OPT is not exactly the right thing, but we're
already using it to enable EME in
browser/config/mozconfigs/win64-aarch64/common-opt and is only set on
those builds.
Differential Revision: https://phabricator.services.mozilla.com/D23639
Since these are compile-time constants, they can't exactly go away on us due to
running script, right?
Differential Revision: https://phabricator.services.mozilla.com/D24195
--HG--
extra : moz-landing-system : lando
We need to typecheck the trivials too, not just the final thing after trivials
are stripped, because casts are trivials.
Differential Revision: https://phabricator.services.mozilla.com/D24186
--HG--
extra : moz-landing-system : lando
The old code for member method calls did the following:
1) Find the member method calls.
2) Look at their "this" expression.
3) If the "this" is an operator call, check for any of the arguments of the
operator call being invalid.
4) Otherwise (if not an operator call) check for the "this" value being
invalid.
This wasn't right, because the "is invalid" check checks the type and only
considers refcounted things. So if the code looked something like
"foo[i]->call_method()", we would look at the types of "foo" and "i" and
determine that none of those are refcounted types so there is nothing invalid
here (since "foo" is some sort of array type and "i" is an integer). The new
setup just checks whether the "this" value is invalid, which does the type
check on the "this" value itself; in the "foo[i]->call_method()" case on
"foo[i]". We then adjust the exclusions in InvalidArg to consider operator->
on known-live things valid, to allow the thing that we were really trying to
accomplish with the "check for an operator call" bits:
"stackRefPtr->some_method()".
The test coverage being added for the made-up TArray type is meant to catch
things like the geolocation issue that was being hidden by the buggy behavior.
I'm not using nsTArray itself because some header included by nsTArray.h
tries to define operator new/delete bits inline and that triggers warnings that
then cause a clang-plugin test failure, because they're unexpected.
Differential Revision: https://phabricator.services.mozilla.com/D24117
--HG--
extra : moz-landing-system : lando
"this" is guaranteed to stay alive as long as other MOZ_CAN_RUN_SCRIPT
conditions hold, and its const members can't change value and drop
their refs.
Differential Revision: https://phabricator.services.mozilla.com/D23997
--HG--
extra : moz-landing-system : lando
This allows calling a C++ MOZ_CAN_RUN_SCRIPT method that takes a callback argument.
The changes to TestCanRunScript.cpp are there to catch an incorrect change I was
going to make to the analysis to make this work, until I figured out that
RootedCallback should be MOZ_IS_SMARTPTR_TO_REFCOUNTED.
Differential Revision: https://phabricator.services.mozilla.com/D23519
--HG--
extra : moz-landing-system : lando
Without this flag, Android PGO profile-use builds may fail with
"Function control flow change detected" errors.
Differential Revision: https://phabricator.services.mozilla.com/D22816
--HG--
extra : moz-landing-system : lando
The file is essentially limited to ARM flag tweaks, so we make the
corresponding python configure code ARM-only. In large parts, the
python code sets things up similarly, although in a few places we try to
be smarter about than the current autoconf-based code.
The resulting config.status have been verified to only have
insignificant differences on both arm and aarch64 android builds.
Depends on D24000
Differential Revision: https://phabricator.services.mozilla.com/D24001
--HG--
extra : moz-landing-system : lando
The file is essentially limited to ARM flag tweaks, so we make the
corresponding python configure code ARM-only. In large parts, the
python code sets things up similarly, although in a few places we try to
be smarter about than the current autoconf-based code.
The resulting config.status have been verified to only have
insignificant differences on both arm and aarch64 android builds.
Depends on D24000
Differential Revision: https://phabricator.services.mozilla.com/D24001
--HG--
extra : moz-landing-system : lando
See https://bugs.llvm.org/show_bug.cgi?id=38944. clang thought it could safely leave out type information for some of our classes, but that information would have been helpful for debugging. The flag in this patch turns off the debug-info limiting.
Differential Revision: https://phabricator.services.mozilla.com/D24073
--HG--
extra : moz-landing-system : lando
Without this flag, Android PGO profile-use builds may fail with
"Function control flow change detected" errors.
Differential Revision: https://phabricator.services.mozilla.com/D22816
--HG--
extra : source : 3dfc0e4f8e7c8cd48b911033222fb3c3edb9762b
In at least some libstdc++ versions, std::pair (which we want to be
memmovable) inherits from __pair_base. We have a similar setup
already for __atomic_base.
Differential Revision: https://phabricator.services.mozilla.com/D23698
--HG--
extra : moz-landing-system : lando
We do this to encourage clang to find an new-enough linker instead of
the system one.
Differential Revision: https://phabricator.services.mozilla.com/D22881
--HG--
extra : moz-landing-system : lando
We want our clang bootstrap to use the GCC headers we're building with,
not whatever sysroot it happens to find on the server we're building on.
The -gcc-toolchain argument we specify when building clang will also be
picked up by llvm-config, so we need to strip it out when building the
plugin. Otherwise, we will get peculiar failures about not being able to
find C++ header files.
Differential Revision: https://phabricator.services.mozilla.com/D22880
--HG--
extra : moz-landing-system : lando
Explicit is better than implicit, and helps ensure that GCC is always
using the binutils we built it with, rather than the system binutils.
Differential Revision: https://phabricator.services.mozilla.com/D22879
--HG--
extra : moz-landing-system : lando
Updating clang indicates that 32-bit compilation is substantially longer
than 64-bit compilation, perhaps due to swapping. The compilation
process is hitting the timeout limit shortly before the compilation
process completes (~3681/3695 tasks according to ninja).
We could tweak our clang build process to accommodate this job. But we
don't support building on 32-bit Windows anymore, and we don't produce a
32-bit Windows clang either. So we shouldn't support a 32-bit Windows
clang-tidy job either. Let's get rid of it.
Differential Revision: https://phabricator.services.mozilla.com/D23517
--HG--
extra : moz-landing-system : lando
We do this to encourage clang to find an new-enough linker instead of
the system one.
Differential Revision: https://phabricator.services.mozilla.com/D22881
--HG--
extra : moz-landing-system : lando
We want our clang bootstrap to use the GCC headers we're building with,
not whatever sysroot it happens to find on the server we're building on.
The -gcc-toolchain argument we specify when building clang will also be
picked up by llvm-config, so we need to strip it out when building the
plugin. Otherwise, we will get peculiar failures about not being able to
find C++ header files.
Depends on D22879
Differential Revision: https://phabricator.services.mozilla.com/D22880
--HG--
extra : moz-landing-system : lando
Explicit is better than implicit, and helps ensure that GCC is always
using the binutils we built it with, rather than the system binutils.
Differential Revision: https://phabricator.services.mozilla.com/D22879
--HG--
extra : moz-landing-system : lando
The only place we'd need the compat libraries would be for host
binaries, and those shouldn't be a problem given that our system images
are new enough.
Differential Revision: https://phabricator.services.mozilla.com/D22873
--HG--
extra : moz-landing-system : lando
A newer clang may require newer binutils than the system provides, so we
should ensure that we provide just such a binutils.
Differential Revision: https://phabricator.services.mozilla.com/D23393
--HG--
extra : moz-landing-system : lando
These toolchain tasks are the last ones using the historical
download-tools script from build/unix/build-gcc, which invokes gpg to
validate the downloaded tarballs. The consequence is that gpg-agent is
spawned and stays running, preventing a cleanup script from doing its
job, making the tasks fail.
Fetches are the new way to download sources, and can also do gpg
validation without those caveats.
The download-tools.sh script can then be removed as it's not used
anymore.
Differential Revision: https://phabricator.services.mozilla.com/D22682
--HG--
extra : moz-landing-system : lando
This way if a caller calls a method that has a MOZ_CAN_RUN_SCRIPT override, it
can detect that it's possibly calling a MOZ_CAN_RUN_SCRIPT thing without having
to know about the override.
Differential Revision: https://phabricator.services.mozilla.com/D22839
--HG--
extra : moz-landing-system : lando
It's occasionally useful to know what versions are being discovered for
these variables. It's also convenient for logs from automation to
contain all the relevant information, rather than setting up a loaner
and running all the commands yourself.
Differential Revision: https://phabricator.services.mozilla.com/D22385
--HG--
extra : moz-landing-system : lando
Artifact mozconfigs are not necessarily up-to-date wrt changes to the
nightly mozconfigs, and all in all, shouldn't be much different from
them.
It's just better to use the nightly mozconfigs (or beta on beta, etc.)
and make the mozconfigs themselves handle the few things that need to be
different when the USE_ARTIFACT environment is set (which is now
consistently set by taskcluster)
This does have the side effect of turning builds that actually don't
support artifact builds red when using --artifact on try, instead of
having them silently not be artifact builds as currently happens.
Depends on D21314
Differential Revision: https://phabricator.services.mozilla.com/D21315
--HG--
extra : moz-landing-system : lando
The artifact builds that are automatically derived using the artifact
template set the USE_ARTIFACT environment variable from taskcluster.
After the previous change, --artifact builds from try syntax do that
too.
That leaves us with only the artifact-build build not doing it, so for
consistency, do it there. That makes it not necessary to set
USE_ARTIFACT from mozconfig.artifact.automation anymore.
Depends on D22056
Differential Revision: https://phabricator.services.mozilla.com/D21313
--HG--
extra : moz-landing-system : lando
The existing ANR and tombstone checks in remoteautomation are used
by mochitests and reftests but are awkward for other harnesses like cppunit
that do not use remoteautomation...and easily missed. This patch moves that
code to the mozharness AndroidMixin, treating ANRs and tombstones like the
logcat: Make sure any old logs are deleted when the mozharness script starts,
then move any logs found at the end of the run to the upload directory.
https://treeherder.mozilla.org/#/jobs?repo=try&tier=1%2C2%2C3&revision=f3de1e9836da2b0c9232f5d92c751b979459e19b
demonstrates tombstone artifacts for the Android 7.0 cppunit tests.
Differential Revision: https://phabricator.services.mozilla.com/D21774
--HG--
extra : moz-landing-system : lando
Optimizing jars without preloading/reordering data only moves the
jar central directory to the beginning of the file, which, without
preloading information, is not very useful. Let's just stop doing it if
there's not going to be preloading/reordering information at all.
Differential Revision: https://phabricator.services.mozilla.com/D21170
--HG--
extra : moz-landing-system : lando
This patch adds detection for when icecream is in use to build telemetry.
icecream is commonly enabled in two ways: by either setting CC/CXX to point
to icecream's cc/c++ symlinks, or by setting adding
mk_add_options 'export CCACHE_PREFIX=icecc' to a mozconfig when also using
ccache. For the former, this patch adds a simple configure check to see
if CXX is a symlink to a file named 'icecc'. For the latter this patch adds
CCACHE_PREFIX as a configure subst to capture the value.
We don't currently have a facility for writing telemetry tests that depend on
configure values. Local manual testing shows that it does work as expected.
Differential Revision: https://phabricator.services.mozilla.com/D18138
--HG--
extra : moz-landing-system : lando
Android requires us to use -fprofile-generate / -fprofile-use instead of
-fprofile-instr-generate / -fprofile-instr-use. Additionally, we have
to pass in the path to write out the profile data as /data/local/tmp,
since the cwd from where the Fennec process is invoked is not writeable.
Differential Revision: https://phabricator.services.mozilla.com/D20697
--HG--
extra : moz-landing-system : lando
In bug 1522354, we changed host and target detection to not invoke
config.sub, assuming the output from config.guess would satisfy our
needs in split_target.
It turns out that on some plaforms, that doesn't work out, so, while we
still skip config.sub, we now catch errors from split_target when doing
so, and try again after running config.sub when split_target fails.
Differential Revision: https://phabricator.services.mozilla.com/D19937
Noemi Erli
Mike Hommey
Sylvestre Ledru
Andi-Bogdan Postelnicu
Masatoshi Kimura
Nick Alexander
Emilio Cobos Álvarez
Ciure Andrei
Andreea Pavel
Oana Pop Rus
Daniel Varga
Chris Manchester
Geoff Brown
Tom Prince
Thomas Daede
Boris Zbarsky
Gurzau Raul
David Major
Coroiu Cristina
Makoto Kato
Jesse Schwartzentruber
Nicholas Nethercote
Csoregi Natalia
shindli
Brindusan Cristian
Mike Shal
Wes Kocher
Gian-Carlo Pascutto
Nathan Froyd
Nathan Froyd
Carolina Jimenez Gomez
James Willcox
Johann Hofmann
Ted Mielczarek
Kartikaya Gupta
Bogdan Tara
Cosmin Sabou
Chris Hartjes
Marco Castelluccio
Razvan Maries