Getting rid of unneeded code and having fewer global defines are both
worthy things.
Differential Revision: https://phabricator.services.mozilla.com/D45726
--HG--
extra : moz-landing-system : lando
A previous patch defined `_LIBCPP_HIDE_FROM_ABI` to the empty string.
This definition worked for normal (opt/debug) builds, but
PGO-instrumented builds fell over with some linker errors. A closer
look at the definition of `_LIBCPP_HIDE_FROM_ABI`:
```
#ifndef _LIBCPP_HIDE_FROM_ABI_PER_TU
# ifndef _LIBCPP_HIDE_FROM_ABI_PER_TU_BY_DEFAULT
# define _LIBCPP_HIDE_FROM_ABI_PER_TU 0
# else
# define _LIBCPP_HIDE_FROM_ABI_PER_TU 1
# endif
#endif
#ifndef _LIBCPP_HIDE_FROM_ABI
# if _LIBCPP_HIDE_FROM_ABI_PER_TU
# define _LIBCPP_HIDE_FROM_ABI _LIBCPP_HIDDEN _LIBCPP_INTERNAL_LINKAGE
# else
# define _LIBCPP_HIDE_FROM_ABI _LIBCPP_HIDDEN _LIBCPP_EXCLUDE_FROM_EXPLICIT_INSTANTIATION
# endif
#endif
```
says that there are two macros involved there: one to set hidden visibility
(which we don't want), and another to exclude the function definition
from explicit instantiation. The semantics of this are not obvious (the
clang documentation only documents this attribute in terms of C++
templates; the particular case we're interested in sets the attribute on
normal function definitions). But roughly, what this does is that it
forces the compiler to see that an equivalent function definition is
provided external to the compilation unit, so it doesn't have to keep
the annotated function definition around.
Differential Revision: https://phabricator.services.mozilla.com/D45073
--HG--
extra : moz-landing-system : lando
If the run task generates bad profile data, the merge step in the
profile-use task will fail. However, retrying the profile-use task
doesn't fix the problem, and there isn't a straightforward way to retry
the run task in this situation. Instead we can add a clang toolchain to
all the run tasks, and perform the merge there.
This means the output from the run task will always be a successfully
merged file called 'merged.profdata', and we no longer need to perform
the merge as part of the profile-use build as a GENERATED_FILES step.
Depends on D45262
Differential Revision: https://phabricator.services.mozilla.com/D45263
--HG--
extra : moz-landing-system : lando
This is needed in the following patch, but the diff is more clear with
this split out.
Differential Revision: https://phabricator.services.mozilla.com/D45262
--HG--
extra : moz-landing-system : lando
With the migration from AWS to GCP, we also need to migrate sccache
buckets from S3 to Google Storage.
The problem is how we deal with regions, since there isn't an exact
correspondence on the region names between the two cloud providers.
To make the transition smoother, docker-worker (and soon generic-worker)
provides a new environment variable called TASKCLUSTER_WORKER_LOCATION,
with information about the cloud provider the task is running on. Using
this new variable, we configure sccache to use the corresponding storage
service of the cloud provider where the task runs.
The bucket names in Google Storage are shorter because GCS imposes a
limit of 30 characteres for the names.
Ref: https://github.com/taskcluster/taskcluster-rfcs/pull/148/files
Differential Revision: https://phabricator.services.mozilla.com/D44845
--HG--
extra : moz-landing-system : lando
One less thing for configurations to vary is a good thing. This change
also means that when we do NDK bumps that introduce some kind of weird
incompatible change, configuration with a newly-pulled tree and an old
NDK halts at configure, rather than giving weird build errors.
Differential Revision: https://phabricator.services.mozilla.com/D44705
--HG--
extra : moz-landing-system : lando
We define some libc++-internal macros to avoid conflicts between the way
we do symbol visibility and the way libc++ expects visibility to work.
Newer NDK versions use a newer libc++ which changes the way the macro we
were using works. To enable building with newer libc++ versions, let's
also define macros appropriate to those versions as well.
Differential Revision: https://phabricator.services.mozilla.com/D44510
--HG--
extra : moz-landing-system : lando
We have an `ndk_version_major` and an `ndk_version_minor` that have a
lot of duplicated code in them. We could factor them into a single
function, but it seems better to just pull their logic into `ndk_version`
directly, rearranging that function to be IMHO more understandable.
Differential Revision: https://phabricator.services.mozilla.com/D44506
--HG--
extra : moz-landing-system : lando
Credit: mars for making the shell POSIX compliant
This embeds a blacklist of every mach command that needs to run with Python 2
directly in the mach driver itself. Initially this is every mach command. We
then use a bit of shell to determine whether the command being run needs Python
2 or 3.
While this approach may seem a bit hacky, it has several benefits:
1. No need to add complex machinery in mach's registration code.
2. No need to spawn two separate Python interpreters in the event a different
Python from the original interpreter is needed.
3. Perf impact is negligible.
4. New commands are Python 3 by default.
It is also only a temporary hack. Once all commands are running with Python 3,
we can revert back to the original mach driver.
Differential Revision: https://phabricator.services.mozilla.com/D36103
--HG--
extra : moz-landing-system : lando
common.gypi uses hard-coded absolute path for echo command, but this path
is invalid on Windows.
But this lines are unused, so we should remove it.
Differential Revision: https://phabricator.services.mozilla.com/D42779
--HG--
extra : moz-landing-system : lando
Also don't pass universal_newlines to check_cmd_output. That was added
to make python 3 happier when check_cmd_output still returned bytes, to
hint subprocess to return a unicode string, but now that
check_cmd_output does the decoding, that's not needed anymore.
Differential Revision: https://phabricator.services.mozilla.com/D43205
--HG--
extra : moz-landing-system : lando
The discrepancy of features used for syn between jsrust and gkrust
triggered syn and its reverse dependencies up to cranelift to be
built once for jsrust and once for gkrust, while they are time consuming
to build.
Differential Revision: https://phabricator.services.mozilla.com/D43209
--HG--
extra : moz-landing-system : lando
This change looks a lot more complicated than it actually is.
The motivating issue is that on x86-64 android, the NDK uses gold as its
default linker, and on this platform gold has some bugs in how it handles
`.note.*` sections that lead to `strip` and `objcopy` produce invalid
binaries...or at least invalid binaries according to `elfhack`. When
`elfhack` complains, the build stops, which is suboptimal. Instead, let's
use bfd `ld`, which doesn't have these problems.
Except that when we make the change to provide `--enable-linker` with a
platform-specific default, the lint configure tests complain that the
provided help string is not using the proper format. So we tack on the
sekret `{|}` string to satisfy the linter.
Differential Revision: https://phabricator.services.mozilla.com/D43098
--HG--
extra : moz-landing-system : lando
For some reason, cargo incremental doesn't work as well as it should,
and doesn't perform as well as sccache does. So when building with
sccache, disable cargo incremental. This brought a no-change clobber
build with 100% cache from 3:50 to 2:05 on a beefy AWS instance I was
testing this with.
Differential Revision: https://phabricator.services.mozilla.com/D43188
--HG--
extra : moz-landing-system : lando
Bug 1575135 changed check_cmd_output to return unicode strings, but a
couple places were already trying to do their own decoding, which now
can fail. Remove those.
Interesting the decoding was previously broken on Windows, this
actually fixes it (the output of hg config is not actually utf-8 on
Windows).
Differential Revision: https://phabricator.services.mozilla.com/D43044
--HG--
extra : moz-landing-system : lando