iOS support for Gecko has not been tested in years and is most probably
out of date. The build system part of it, specifically the checks in
build/autoconf/ios.m4, are not trivial to port to python configure, and
they prevent other things from moving to python configure (because some
of them change value when MOZ_IOS is set).
The code is left alone, although it could probably be stripped off as
well, but I'll leave that as an exercise for someone else.
Differential Revision: https://phabricator.services.mozilla.com/D75463
Dictionary iteration under Python 3 is in an inherently unpredictable order, and while we try to keep DEFINES ordered through the use of OrderedDicts, if at any point we populate DEFINES directly or indirectly while iterating through the contents of a non-ordered dictionary, the order of the DEFINES (and therefore the contents of the output Makefile) will be nondeterministic as well. This patch makes a number of changes to ensure that we only ever populate DEFINES in a deterministic fashion. (Note that in Python 3.7 and later, the built-in dict class actually has deterministic ordering, so these changes are technically only necessary until our minimum Python version becomes 3.7.)
Differential Revision: https://phabricator.services.mozilla.com/D66089
--HG--
extra : moz-landing-system : lando
Dictionary iteration under Python 3 is in an inherently unpredictable order, and while we try to keep DEFINES ordered through the use of OrderedDicts, if at any point we populate DEFINES directly or indirectly while iterating through the contents of a non-ordered dictionary, the order of the DEFINES (and therefore the contents of the output Makefile) will be nondeterministic as well. This patch makes a number of changes to ensure that we only ever populate DEFINES in a deterministic fashion. (Note that in Python 3.7 and later, the built-in dict class actually has deterministic ordering, so these changes are technically only necessary until our minimum Python version becomes 3.7.)
Differential Revision: https://phabricator.services.mozilla.com/D66089
--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
This change is a little gross, because we don't totally control where
the statically initialized instances of `RWLock` live, due to its uses
in third-party libraries.
Differential Revision: https://phabricator.services.mozilla.com/D62936
--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
"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
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
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
ICU changes the numbering system of date formats which include an era marker
to "jpanyear". "jpanyear" is a rule-based numbering system and therefore the
RBNF data for the Japanese locale now need to be included.
Differential Revision: https://phabricator.services.mozilla.com/D27340
--HG--
extra : moz-landing-system : lando
André Bargull
Mike Hommey
Anthony Ramine
Ricky Stewart
Narcis Beleuzu
Marco Bonardo
Mike Shal
Csoregi Natalia
Nathan Froyd
Cosmin Sabou
Brindusan Cristian
Sylvestre Ledru
shravanrn@gmail.com
Daniel Varga
championshuttler
Justin Wood
Ehsan Akhgari