- `info.type in ('clang-cl', 'clang', 'gcc')` is always true since MSVC
support was removed.
- For some reason, we didn't enforce C++14 on GCC.
Differential Revision: https://phabricator.services.mozilla.com/D34990
--HG--
extra : moz-landing-system : lando
Improve support for Python 3 by running modernize over adb.py and a few other related changes.
Differential Revision: https://phabricator.services.mozilla.com/D19306
--HG--
extra : moz-landing-system : lando
We've been relying on frame pointers being indirectly enabled via things
like --enable-profiling for some time, but this doesn't scale because
some things may want frame pointers while wanting --disable-profiling.
So we move MOZ_FRAMEPTR_FLAGS to python configure and add a new option
to decide whether to enable frame pointers or not.
Differential Revision: https://phabricator.services.mozilla.com/D34117
--HG--
extra : moz-landing-system : lando
Bug 1394825 bumped the minimum version of clang we use on automation,
for the base toolchain jobs, and there's a libclang test for bindgen,
but we should reject the compiler in the first place.
The check to do that works in both C and C++, contrary to the original
3.6 test that was checking a C++ feature ; the test was later changed
for 3.9, using a check that would have worked in both C and C++, but
the C exception was left around. We remove it now.
Differential Revision: https://phabricator.services.mozilla.com/D34083
--HG--
extra : moz-landing-system : lando
Stand-alone JS builds now default to without-NSPR on all platforms.
Note that the JS shell builds we do in automation pass --enable-nspr-build so they shouldn't be affected by
the JS shell changes.
Differential Revision: https://phabricator.services.mozilla.com/D33933
--HG--
extra : moz-landing-system : lando
Use the same logic as for --with-android-sdk to use the NDK downloaded
by mach bootstrap by default.
Differential Revision: https://phabricator.services.mozilla.com/D34251
--HG--
extra : moz-landing-system : lando
We make it have a default value only if the corresponding directory exists,
and make it throw a more explicit error when the explicitly given directory
doesn't exist.
Differential Revision: https://phabricator.services.mozilla.com/D34250
--HG--
extra : moz-landing-system : lando
The current logic is that if the compiler somehow uses gold rather than
BFD ld by default, we let it, but if it uses BFD ld, we default to lld.
When doing Android builds, the compiler finds the linker in the NDK, and
the default `ld` binary is gold. So we currently end up using fold for
Android builds.
Here, we change the logic such that we use lld when the default linker
the compiler uses is either BFD ld or gold. We can't go with "is not
lld" because the other possible kind, ld64, is what we actually want to
use on mac, since lld doesn't support mach-o fully just yet.
Differential Revision: https://phabricator.services.mozilla.com/D34040
--HG--
extra : moz-landing-system : lando
The current logic is that if the compiler somehow uses gold rather than
BFD ld by default, we let it, but if it uses BFD ld, we default to lld.
When doing Android builds, the compiler finds the linker in the NDK, and
the default `ld` binary is gold. So we currently end up using gold for
Android builds.
Here, we change the logic such that we use lld when the default linker
the compiler uses is either BFD ld or gold. We can't go with "is not
lld" because the other possible kind, ld64, is what we actually want to
use on mac, since lld doesn't support mach-o fully just yet.
Differential Revision: https://phabricator.services.mozilla.com/D34040
--HG--
extra : moz-landing-system : lando
https://reviews.llvm.org/rL360311 reworked the handling of `explicit` in `CXXConversionDecl`, and the `isExplicitSpecified()` method no longer exists. We can instead use `isExplicit()` which conveniently works on both old and new clangs. (Before 360311, `isExplicit()` just forwarded to `isExplicitSpecified()`.)
Differential Revision: https://phabricator.services.mozilla.com/D33958
--HG--
extra : moz-landing-system : lando
Valgrind report:
```
TEST-UNEXPECTED-FAIL | valgrind-test | 192 bytes in 3 blocks are definitely lost at malloc / dl_open_worker / _dl_catch_error / _dl_open
==2561== 192 bytes in 3 blocks are definitely lost in loss record 348 of 399
==2561== at 0x4C2B240: malloc+112 (vg_replace_malloc.c:298)
==2561== by 0x4012919: dl_open_worker+1977 (dl-open.c:457)
==2561== by 0x400DD55: _dl_catch_error+101 (dl-error.c:178)
==2561== by 0x4011CC9: _dl_open+185 (dl-open.c:633)
==2561== by 0x5051F65: dlopen_doit+101 (dlopen.c:67)
==2561== by 0x400DD55: _dl_catch_error+101 (dl-error.c:178)
==2561== by 0x50522EB: _dlerror_run+123 (dlerror.c:164)
==2561== by 0x5051EE0: dlopen@@GLIBC_2.2.5+48 (dlopen.c:88)
==2561== by 0x1148FC: GetLibHandle (xpcom/glue/standalone/nsXPCOMGlue.cpp:86)
==2561== by 0x1148FC: ReadDependentCB (xpcom/glue/standalone/nsXPCOMGlue.cpp:136)
==2561== by 0x1148FC: XPCOMGlueLoad (xpcom/glue/standalone/nsXPCOMGlue.cpp:306)
==2561== by 0x1148FC: mozilla::GetBootstrap(char const*, mozilla::LibLoadingStrategy)+572 (xpcom/glue/standalone/nsXPCOMGlue.cpp:374)
==2561== by 0x114213: InitXPCOMGlue(mozilla::LibLoadingStrategy)+131 (browser/app/nsBrowserApp.cpp:223)
==2561== by 0x113E6B: main+219 (browser/app/nsBrowserApp.cpp:284)
```
Nothing due directly to this patch, so it is likely a dlopen issue.
Differential Revision: https://phabricator.services.mozilla.com/D33904
--HG--
extra : moz-landing-system : lando
The current setup for bindgen relies on either finding clang/libclang
from the output of llvm-config, or from the paths given via the
configure flags --with-clang-path/--with-libclang-path.
One _very_ common problem is that the llvm-config we end up using does
not correspond to the clang used for compilation, which has some
undesirable side effect, like failing to build.
So instead of relying on llvm-config, we do the following:
- when the compiler is clang, we just use that
- when the compiler is clang-cl, we use clang from the same directory
- otherwise, we either try to find clang in PATH, or rely on
--with-clang-path.
Once clang is found, we try to deduce the location of the corresponding
libclang via the output of `clang -print-search-dirs`, or rely on
--with-libclang-path.
Differential Revision: https://phabricator.services.mozilla.com/D33241
--HG--
extra : moz-landing-system : lando
Inheriting constructors are implicitly introduced via a using-declaration.
Since the C++ grammar doesn't allow attributes on using-declarations, it
is currently impossible to add MOZ_IMPLICIT to implicit inheriting
constructors.
This commit changes the AST matcher such that it ignores inheriting
constructors altogether. If they are inheriting from an implicit inherited
constructor, that constructor's check should be enough to ensure that no
constructors are unintentionally implicit.
Differential Revision: https://phabricator.services.mozilla.com/D33281
--HG--
extra : moz-landing-system : lando
This code was already dead during the VS2017 era (since that compiler changed to the `Hostx64\x86` path scheme), let alone clang-cl.
Differential Revision: https://phabricator.services.mozilla.com/D33513
--HG--
extra : moz-landing-system : lando
The 3-tier PGO builds used a separate mozconfig called 'profile-use' for
the final tier. This created a problem when it rode to beta, since the
same mozconfig was used for all trees, which meant we ended up with
nightly branding on beta builds.
With the PGO-enabling logic in common mozconfigs, we can enable it by
setting the MOZ_PGO_PROFILE_USE environment variable from the task
definition. All of the final-tier PGO builds now use the nightly, beta,
etc mozconfigs like before, so branding should be intact.
Differential Revision: https://phabricator.services.mozilla.com/D33172
--HG--
extra : moz-landing-system : lando
This change is a little bit of a cheat, because of course MSVC doesn't
do cross-language LTO by default, but it seems consistent.
Depends on D33317
Differential Revision: https://phabricator.services.mozilla.com/D33318
--HG--
extra : moz-landing-system : lando
- DISABLE_SHARED_JS and DISABLE_EXPORT_JS have been deprecated for 3
years,
- MOZ_JEMALLOC4 has been deprecated for 2 years.
Differential Revision: https://phabricator.services.mozilla.com/D32928
--HG--
extra : moz-landing-system : lando
Negative value for import level is obsolete in Python 3, which was used on Py2 for implicit relative import. This change ensures the level value to be >=0 on Py3 to fix test failures.
Differential Revision: https://phabricator.services.mozilla.com/D32497
--HG--
extra : moz-landing-system : lando
The exit code from valgrind may subtly indicate how it failed (like, if
it's 139 or 137, which would mean respectively segfault or killed by
something external), which is currently completely hidden, making
diagnostics of things like bug 1545094 harder.
Differential Revision: https://phabricator.services.mozilla.com/D32412
--HG--
extra : moz-landing-system : lando
We're moving to IR-level PGO instrumentation for clang-cl. We've also
moved to using static linker ordering files, which was the primary
application of the previous style of PGO instrumentation. We therefore
we no longer need this code.
Differential Revision: https://phabricator.services.mozilla.com/D31134
--HG--
extra : moz-landing-system : lando
This form of instrumentation is more like our other platforms, and also
opens the possibility of interacting properly with Rust IR-level PGO.
Differential Revision: https://phabricator.services.mozilla.com/D31133
--HG--
extra : moz-landing-system : lando
We're planning on switching to IR-based profiling, so we can't use the
frontend-based instrumentation to collect the order in which functions
are executed...at least not during the build itself. Performance tests
indicate that not having the order information decreases performance
significantly. So we're going to check in static files for Win32 and
Win64 and use those to perform the ordering. It's OK if these files are
slightly out of date; as of this writing, builds that generate and then
use these files complain that ~1/3 of the functions can't be found (!).
We're just trying to do something slightly smarter than whatever the
linker default is.
Differential Revision: https://phabricator.services.mozilla.com/D31132
--HG--
extra : moz-landing-system : lando
e10s profiling or IR-based PGO instrumentation will both produce
multiple `.profraw` files that need to be handled in some way. Since
clang's `-fprofile-generate` option takes a directory, it seems fitting
to make `--with-pgo-profile-path` mirror that by taking a directory, and
letting `merge_profdata.py` deal with whatever files it might find in
said directory.
Differential Revision: https://phabricator.services.mozilla.com/D32389
--HG--
extra : moz-landing-system : lando
Wes Kocher
Mike Hommey
Marian Raiciof
Chris Manchester
Bob Clary
Jan de Mooij
Bogdan Tara
David Major
Gerald Squelart
Andrew Sutherland
Yaron Tausky
Mike Shal
Cosmin Sabou
Nathan Froyd
Gijs Kruitbosch
Mark Banner
Mihai Alexandru Michis
Ehsan Akhgari
Kagami Sascha Rosylight
Justin Wood
Brindusan Cristian