Turns out we were using the Linux ones. This uses the Windows ones, and
adds _HAS_EXCEPTIONS to the mingw defines so the stl_wrappers behave
correctly.
Differential Revision: https://phabricator.services.mozilla.com/D54530
--HG--
extra : moz-landing-system : lando
Turns out we were using the Linux ones. This uses the Windows ones, and
adds _HAS_EXCEPTIONS to the mingw defines so the stl_wrappers behave
correctly.
Differential Revision: https://phabricator.services.mozilla.com/D54530
--HG--
extra : moz-landing-system : lando
In 1-tier PGO builds that shared the objdir between the instrumented and
profile-use builds, the instrumented build objects used a different
suffix (.i_o) to separate them from the profile-use build (which uses
the default .o suffix). These builds are now always in separate objdirs,
and don't need special suffix rules anymore.
As a bonus, this helps fix an issue with buildid.cpp continually
rebuilding because libxul_so.list always lists the inputs as *.o, which
don't exist if we're using a .i_o suffix. Make would always re-create
buildid.cpp and therefore libxul.so in the instrumented build even when
nothing has changed.
Differential Revision: https://phabricator.services.mozilla.com/D56115
--HG--
extra : moz-landing-system : lando
This was used for Windows MSVC PGO builds that re-used the objdir. We
don't use MSVC for PGO anymore, and we don't re-use the objdir.
Differential Revision: https://phabricator.services.mozilla.com/D56114
--HG--
extra : moz-landing-system : lando
MOZ_1TIER_PGO was a temporary hack to support 1-tier PGO builds while
they were being ported to 3-tier. Now that all builds are 3-tier, it can
be removed.
Differential Revision: https://phabricator.services.mozilla.com/D56112
--HG--
extra : moz-landing-system : lando
Add backend stuff to build sandboxed wasm libraries. (Don't actually update any moz.build files to consume this yet.)
Differential Revision: https://phabricator.services.mozilla.com/D54152
--HG--
extra : moz-landing-system : lando
To get an accurate backtrace if the run task crashes, we need the
symbols from the instrumented build.
Depends on D53716
Differential Revision: https://phabricator.services.mozilla.com/D53717
--HG--
extra : moz-landing-system : lando
This file provides the implementation of js/Utility.h, so it should be renamed
to match the header name.
Differential Revision: https://phabricator.services.mozilla.com/D51378
--HG--
rename : js/src/jsutil.cpp => js/src/util/Utility.cpp
extra : moz-landing-system : lando
For files with lots of dependencies (i.e. libxul), printing out the
entire list of changed files can be tedious. Instead, let's pick some
reasonable limit for the number of files we'll explicitly show, and
indicate that there are more files (but not print them out) for cases
that exceed that limit.
Differential Revision: https://phabricator.services.mozilla.com/D51913
--HG--
extra : moz-landing-system : lando
The current coreaudio-sys in gecko is a custom 0.2.2 version that used
to avoid the cross-compiling issue mentioned in bug 1569003. The issue
has been fixed in the coreaudio-sys 0.2.3, so we should follow the
upstream instead of using a custom version. As a result, the
coreaudio-sys would generate API bindings based on the MacOS SDK defined
in the build settings.
Differential Revision: https://phabricator.services.mozilla.com/D50531
--HG--
extra : moz-landing-system : lando
.cargo/config is necessary for all invocations of cargo, which, apart
from normal rust targets, actually also happens indirectly when we
invoke cbindgen.
Differential Revision: https://phabricator.services.mozilla.com/D50550
--HG--
extra : moz-landing-system : lando
"disjunction" and "unit" types aren't yet supported, because ICU doesn't
provide a C-API for this functionality. "short" and "narrow" styles aren't
supported for the same reason.
Differential Revision: https://phabricator.services.mozilla.com/D40437
--HG--
extra : moz-landing-system : lando
This does many things:
1) stops producing (and consuming) `FennecJNI*` JNI wrappers
2) removes the :app and :thirdparty Gradle projects
3) removes relevant pieces of the Gradle target configuration
4) updates lints
5) purges old configurations
After this commit, the `mobile/android` project/application builds
only GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D46536
--HG--
extra : moz-landing-system : lando
And add them to the UseCounter enum. Also add some sanity-check assertions that
the reporting code relies on.
This works much like the deprecated operation list.
Differential Revision: https://phabricator.services.mozilla.com/D44696
--HG--
extra : moz-landing-system : lando
And add them to the UseCounter enum. Also add some sanity-check assertions that
the reporting code relies on.
This works much like the deprecated operation list.
Differential Revision: https://phabricator.services.mozilla.com/D44696
--HG--
extra : moz-landing-system : lando
And add them to the UseCounter enum. Also add some sanity-check assertions that
the reporting code relies on.
This works much like the deprecated operation list.
Differential Revision: https://phabricator.services.mozilla.com/D44696
--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
Bug 1578254 added a dependency on .cargo/config to export, which happens
to work in the python/mozbuild/mozbuild/test/backend/test_build.py test
cases because DEPTH=., and make finds the checked-in file .cargo/config
in topsrcdir because VPATH points there. After removing VPATH in bug
1496746, the test no longer finds the file in topsrcdir, and doesn't
have a rule to build it since that exists in the top-level moz.build
file.
Differential Revision: https://phabricator.services.mozilla.com/D45261
--HG--
extra : moz-landing-system : lando
Having a full VPATH for the srcdir sometimes causes make to grab the
wrong prerequisite for a rule, in particular if we have a file in the
srcdir and also generate a file of the same name in the objdir. We don't
really need VPATH anymore though, since most of the information comes
from mozbuild, where we can explicitly list the path to the srcdir or
objdir as necessary.
Differential Revision: https://phabricator.services.mozilla.com/D42968
--HG--
extra : moz-landing-system : lando
One of the things bug 1567616 did was to change how .cargo/config is
preprocessed, from it happening during configure to it happening during
the build. And to make things happen properly, dependencies were added
on the rust targets to ensure the .cargo/config file is created before
they run.
Unfortunately, that changed the order in which Make would run all the
targets while recursing for the compile tier, when the file doesn't
exist first. So instead of starting the compile tier with rust targets,
it would start with most C++, then do rust... which we know to make
builds slower overall because of the need to wait for those rust builds
to finish which C++ has all been dealt with already, and lacking
parallelism during the rust build.
So we force .cargo/config to be generated during export (which it is not
already because OBJDIR_PP_FILES are currently dealt with during misc).
That makes Make still run the rust targets early during the compile
tier.
And while here, we extend the if block in recurse.mk that excludes all
the top-level recursion dependencies when running from subdirectories.
Differential Revision: https://phabricator.services.mozilla.com/D44992
--HG--
extra : moz-landing-system : lando
I'm not sure how things have worked without these headers getting
wrapped, but they need to be for declarations in them to work properly.
Differential Revision: https://phabricator.services.mozilla.com/D44690
--HG--
extra : moz-landing-system : lando
-Fd is the parameter accepted by clang. -PDB is the parameter accepted by lld-link. Additionally, to produce a pdb you apparently also need the -DEBUG flag
Differential Revision: https://phabricator.services.mozilla.com/D43525
--HG--
extra : moz-landing-system : lando
We'll require preprocessing that configure subst files don't allow in
the next change, so prepare for that.
Differential Revision: https://phabricator.services.mozilla.com/D43011
--HG--
extra : moz-landing-system : lando
We don't actually care that much about LTO'ing the rust parts of libxul
for gtests, and not LTO'ing it would save multiple minutes of build time
on automation.
Differential Revision: https://phabricator.services.mozilla.com/D42812
--HG--
extra : moz-landing-system : lando
Make depend files related to object files are only really useful when
the corresponding build targets are being processed. OTOH, when they are
included too broadly, when the build recurses in the same directory for
different targets (e.g. target-objects, target, host-objects and/or
host), it is possible for one of them to start creating depend files
that the others would end up reading, and those reads might be
incomplete, possibly leading to build failures because Make think it's
malformed.
So, we only include the object files's depend files in when Make is
explicitly treating a target that will build objects.
Differential Revision: https://phabricator.services.mozilla.com/D42766
--HG--
extra : moz-landing-system : lando
As a consequence, we can replace the encoded_open function that did the
same in an opt-in manner.
Differential Revision: https://phabricator.services.mozilla.com/D42605
--HG--
extra : moz-landing-system : lando
Android artifacts (GeckoView AARs, GeckoViewExample (and Fennec) APKs)
require native libraries (`libxul.so`) and an omnijar (`omni.ja`).
These are produced by `mach package` (really, the `stage-package`
target). Engineers essentially never want a build without a package
for mobile/android. This adds mobile/android-only tiers that run
`mach package` and then `mach android assemble-app`. The latter
consumes `libxul.so` and `omni.ja` to produce _all the things_
relevant to GeckoView engineers.
Differential Revision: https://phabricator.services.mozilla.com/D41450
--HG--
extra : moz-landing-system : lando
Make the target and host targets depend on those, and flatten the
dependencies.
That is, instead of chains like:
browser/app/target: mozglue/build/target
mozglue/build/target: memory/build/target
we now have:
browser/app/target: browser/app/target-objects \
mozglue/build/target-objects \
memory/build/target-objects
Which means Make can feel free to build the object files in browser/app
before building other dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D42252
--HG--
extra : moz-landing-system : lando
With the addition of toolkit/library/build because of the rust
shenanigans, bug 1573314 and bug 1572046 don't do anything useful
anymore. We're going to do something better anyways.
Differential Revision: https://phabricator.services.mozilla.com/D42251
--HG--
extra : moz-landing-system : lando
Apart from the need to link them last, they don't actually need to be
treated any different from normal static libraries.
Differential Revision: https://phabricator.services.mozilla.com/D42249
--HG--
extra : moz-landing-system : lando
Fixes Thunderbird build bustage related to target-shared.
Investigation into the build issue revealed that this hack is no longer necessary and can be removed. And it's always nice to remove Thunderbird specific code from the build system.
Differential Revision: https://phabricator.services.mozilla.com/D41307
--HG--
extra : moz-landing-system : lando
When a directory, like toolkit/library, builds both a static and a
shared library, and another, like toolkit/library/gtest, depends on the
static part, it currently needs to wait for the shared library to be
finished building, preventing both libraries being built in parallel.
By separating shared libraries to a different target, we allow more
parallelism to the build.
Differential Revision: https://phabricator.services.mozilla.com/D41099
--HG--
extra : moz-landing-system : lando
"confusables" feature:
- Used in 'unicode/uspoof.h' for spoofing detection.
"stringprep" feature:
- Used in 'unicode/usprep.h' for RFC 3454 string preparation.
"unames" feature:
- Used in 'unicode/uchar.h' for `u_charName` to retrieve the name of a Unicode character.
Differential Revision: https://phabricator.services.mozilla.com/D39664
--HG--
extra : moz-landing-system : lando
This gives a nicer error when a sanctioned unit identifier isn't supported by
the current ICU.
Differential Revision: https://phabricator.services.mozilla.com/D38337
--HG--
extra : moz-landing-system : lando
We needed these rules and bits for the QT widget port, but there's no
longer a QT port in the tree, so we might as well remove them.
Differential Revision: https://phabricator.services.mozilla.com/D38886
--HG--
extra : moz-landing-system : lando
Actually we set _DEPEND_CFLAGS to both host and target compiler. But if host and target are different compiler type, we may pass invalid option.
Differential Revision: https://phabricator.services.mozilla.com/D38457
--HG--
extra : moz-landing-system : lando
We don't need to run binary checks on the instrumentation builds, only the final optimized build.
Differential Revision: https://phabricator.services.mozilla.com/D38382
--HG--
extra : moz-landing-system : lando
At the same time, make things a little more tangible in the tiers setup
in baseconfig.mk.
Differential Revision: https://phabricator.services.mozilla.com/D37942
--HG--
extra : moz-landing-system : lando
- Add NumberFormatterSkeleton as a helper class to construct a number formatter
skeleton. When the "Intl.NumberFormat Unified API" proposal gets implemented
a more feature-rich class may be necessary.
- In addition to a UNumberFormatter instance, NumberFormatObject now also
stores a UFormattedNumber instance. This avoids a performance regression
compared to creating a new UFormattedNumber object each time a number gets
formatted. (In micro-benchmarks 20% regressions were seen, with a cached
UFormattedNumber the same micro-benchmarks even improved by ~33%.)
- Add accessors for reserved slot values to NumberFormatObject to improve
readibility.
Differential Revision: https://phabricator.services.mozilla.com/D27083
--HG--
extra : moz-landing-system : lando
- The new formatted-value API is still draft-only, so extra U_HIDE_DRAFT_API guards
are currently needed.
- Also moves steps 4-5 of PartitionRelativeTimePattern to native code to reduce code
duplication.
Differential Revision: https://phabricator.services.mozilla.com/D26719
--HG--
extra : moz-landing-system : lando
- The new formatted-value API is still draft-only, so extra U_HIDE_DRAFT_API guards
are currently needed.
- Also moves steps 4-5 of PartitionRelativeTimePattern to native code to reduce code
duplication.
Differential Revision: https://phabricator.services.mozilla.com/D26719
--HG--
extra : moz-landing-system : lando
The hand-written assembly for libffi on aarch64/windows doesn't emit
unwind information. If we ever tried to unwind through these functions,
they'd look like leaf functions, which is decidedly not true and would
cause great pain.
For whatever reason, the original aarch64 libffi functions used
x21/x22/x23/x24 as their (callee-saved) scratch registers. This
convention works on windows as well, but the unwind information on
windows mandates that we start saving callee-saved registers starting
from x19, rather than x21. Rather than rewriting the assembly to use
x19/x20 instead of x21/x22, which would be a large change, we chose
instead to simply save/restore extra registers in the prolog/epilog.
This change does make the stack frame sizes slightly bigger, but an
extra 16 bytes in libffi stack frames should not matter.
The `-TC` change is necessary to make the compiler play nicely with .asm
file suffixes.
Differential Revision: https://phabricator.services.mozilla.com/D35714
--HG--
extra : moz-landing-system : lando
The condition that enabled ELOG to do something has been broken since
bug 279212 landed two years ago, because MAKEFLAGS doesn't contain the
dash for flags, so looking for "-s" never did anything.
Bug 1560527 changed the condition to !BUILD_VERBOSE_LOG, which as of the
previous commit, does work. This would restore the old behavior, at the
expense of build time, since it involves wrapping in a shell script,
which is not necessarily desirable (and hasn't been done for two years
now)
Differential Revision: https://phabricator.services.mozilla.com/D35967
--HG--
extra : moz-landing-system : lando
Bug 1560527 was not supposed to change verbosity for mach build, but it
turns out it did, because the ifeq it copied from one place to another
was wrong in the first place.
While here, replace a ifeq that did work with the now equivalent
BUILD_VERBOSE_LOG.
Differential Revision: https://phabricator.services.mozilla.com/D35966
--HG--
extra : moz-landing-system : lando
Windows 1-tier PGO builds only partially clobber between the
profile-generate and profile-use stages, so that exports/installed files
don't have to be reprocessed. Unfortunately we can't skip the install
manifests in 3-tier PGO because the profile-generate build happens on a
different machine, so we have to differentiate between 1-tier and 3-tier
PGO builds. A new variable, MOZ_1TIER_PGO, is used for this purpose.
Eventually this logic can be cleaned up in bug 1557788 once all PGO
builds use the 3-tier model.
Differential Revision: https://phabricator.services.mozilla.com/D34802
--HG--
extra : moz-landing-system : lando
When we converted our libffi assembly preprocessing to use
`GENERATED_FILES`, we translated `sed 's%/F[dpa][^ ]*%%g'` to use the Python
regular expression `'F[dpa][^ ]*'`. Note that we missed the leading `/` in
the sed expression; omitting that leading slash causes no end of trouble if
you have particular expressions in your assembly file, such as
"FastFailCode". (I'm a little surprised this hasn't bitten us yet.)
The straightfoward fix is to add the leading slash.
But wait, the rabbit hole goes deeper. The actual bit from libffi's
`msvcc.sh` that this was trying to translate was:
```
echo "$cl -nologo -EP $includes $defines $src > $ppsrc"
"$cl" -nologo -EP $includes $defines $src > $ppsrc || exit $?
output="$(echo $output | sed 's%/F[dpa][^ ]*%%g')"
args="-nologo $safeseh $single $output $ppsrc"
echo "$ml $args"
eval "\"$ml\" $args"
result=$?
```
Note that the sed expression is operating on `$output`, which is a
completely *separate* thing from the output from the result of
preprocessing. In `msvcc.sh`, `$output` is actually some arguments that are
supposed to be passed to the assembler, per the above and the only place in
the script that sets `$output` to a non-trivial value:
```
-o)
outdir="$(dirname $2)"
base="$(basename $2|sed 's/\.[^.]*//g')"
if [ -n "$single" ]; then
output="-Fo$2"
else
output="-Fe$2"
fi
if [ -n "$assembly" ]; then
args="$args $output"
else
args="$args $output -Fd$outdir/$base -Fp$outdir/$base -Fa$outdir/$base"
fi
```
Presumably the sed expression is attempting to remove `-Fd` and friends from
`$args` instead of `$output`, but failing badly at doing so.
In any event, the regex substitution the script is doing is unnecessary and,
with the current code, actively harmful. Let's remove the regular
expression substitution entirely.
Differential Revision: https://phabricator.services.mozilla.com/D35705
--HG--
extra : moz-landing-system : lando
Tom Ritter
Andreea Pavel
Mike Shal
ffxbld
Ricky Stewart
Chris Manchester
Jesse Schwartzentruber
Dzmitry Malyshau
Landry Breuil
André Bargull
Mike Hommey
Nathan Froyd
Chun-Min Chang
Christian Holler
Daniel Varga
Nick Alexander
Emilio Cobos Álvarez
Cosmin Sabou
Karl Tomlinson
Kai Engert
championshuttler
Rob Lemley
Makoto Kato
Eric Rahm
Adam Gashlin
Mihai Alexandru Michis
Narcis Beleuzu
Justin Wood
Gijs Kruitbosch