This makes sure that the compiler's view of the stack matches the run-time stack
when we generate code for struct.narrow. The bug crept in here because I
insisted on generating an in-line test for null before calling out to the
instance. But this is unnecessary; the code in the instance can do this just
fine, and null is not a common case here. (And struct.narrow is extremely slow
in any case, as it's just prototype code)
So, move the null check to C++ and generate straight-line code in Rabaldr.
--HG--
extra : rebase_source : 701c7c461683793cfc84f38461507c73eb4e96a0
The encodings are specified at the very bottom of
https://github.com/WebAssembly/bulk-memory-operations/blob/master/proposals/bulk-memory-operations/Overview.md
I have opted to call the byte memOrTableFlags because that is the
meaning it will eventually have, even though currently the spec calls
it a "memory" (even when the subject is a table).
--HG--
extra : rebase_source : 878e3aa728c34322807d9ea4e7be64d387256ab2
extra : source : 5181d6aefd2cf3881c3d18fc6919b3f5eb9ec576
JS_VOLATILE_ARM was a workaround for a gcc 4.7 bug on B2G where it
would generate unaligned word accesses that should have been
individual byte accesses. We now require at least gcc 6.1 (and ARM
systems support unaligned accesses).
--HG--
extra : rebase_source : a00a0bf0758e009e362275197ac4718c4d02489f
extra : source : 0448c0a2081eb71cf5f9449d9c9f32a2aaa38e2d
Now that the XPCOM component loader infrastructure has stopped
pretending to support other file extensions, this intermediate
interface is no longer needed.
Depends on D8171
Differential Revision: https://phabricator.services.mozilla.com/D8172
--HG--
extra : moz-landing-system : lando
JS is the only file extension actually supported, and there are a few
layers of cruft that can be eliminated if we specialize it.
This eliminates one XPCOM registration of the JS component loader.
Depends on D8170
Differential Revision: https://phabricator.services.mozilla.com/D8171
--HG--
extra : moz-landing-system : lando
This interface is only used for a few testing functions. Just move
them to Cu.
Differential Revision: https://phabricator.services.mozilla.com/D8168
--HG--
extra : moz-landing-system : lando
The desired outcome of this change is that we'll set
-Wl,--version-script based on linker kind and not on the output of
$LINKER -v.
This is a cheap way to address a simple problem that has a complicated
ideal solution. The underlying issue is that in some situations, when
targeting Android, a macOS system ld is interrogated to determine if
a cross-compiling linker "is GNU ld" and a particular linker feature
is set in that situation. The macOS system ld doesn't pass the "is
GNU ld" test, and the linker feature isn't set; that causes link
failures, even though the actual linker has nothing to do with the
system ld.
The ideal solution is to test for linker capabilities dynamically. We
do a lot of that in old-configure.in, and we don't do any of that in
toolchain.configure. Rather than start testing in
toolchain.configure, we hard-code: a cheap solution to the immediate
problem.
MinGW suffers somewhat from the opposite problem: the linker "is GNU
ld" (compatible), but the linker checks don't happen at all. We hard-code
for MinGW based on the C compiler instead.
Differential Revision: https://phabricator.services.mozilla.com/D8471
--HG--
extra : moz-landing-system : lando
SxS assemblies do not obey the usual DLL search order. It will make it possible
to load mozglue.dll from appdir even if the PreferSystem32Images mitigation is
enabled and System32 has a random mozglue.dll.
When we clone the script of a default class constructor (derived or base), we
need to clear its SELF_HOSTED flag, since such functions are supposed to behave
just like ordinary functions from user code: their frames should appear on the
stack, and so on. However, the SELF_HOSTED flag must remain set until the script
is actually cloned from the original, to satisfy the (quite reasonable)
assertion that only SELF_HOSTED functions get their scripts cloned from the
self-hosted compartment.
Depends on D8620
Differential Revision: https://phabricator.services.mozilla.com/D8621
--HG--
extra : moz-landing-system : lando
This function is used only by js::MakeDefaultConstructor, which uses it to
assert that the self-hosted function clone it just created is a default class
constructor. This assertion is not very valuable:
- The function is always a self-hosted builtin, since we created it by calling
createLazySelfHostedFunctionClone a few lines earlier.
- In the self-hosted builtin case, infallibleIsDefaultClassConstructor can't
consult the script's isDefaultClassConstructor predicate, so it just checks
the function's LAZY_FUNCTION_NAME_SLOT, verifying that it is one of the two
names supplied in MakeDefaultConstructor, also a few lines above the call.
- It then asserts that, if the function is a default class constructor, its
`isConstructor` and `isClassConstructor` predicates agree. This is also
checked in MakeDefaultConstructor.
So the checks are superfluous.
In the next patch, we want to clear the SELF_HOSTED flag on default
constructors, since they should appear in all respects as if they originated
with the class declaration, in user code. Having a predicate like
infallibleIsDefaultClassConstructor around insisting that they must be
self-hosted builtins would be confusing.
Differential Revision: https://phabricator.services.mozilla.com/D8620
--HG--
extra : moz-landing-system : lando
In FxAccountsComponents.manifest, the previous line registers the
component CID, but only for the main process. This means we hit an
error while parsing the manifest in the child process, because the CID
is not recognized. The fix is simply to not try to use the CID to
register the contract in the child process.
As for the rest of the changes, since bug 1438688, XPT information is
compiled into the Firefox binary, so the interfaces manifest entry is
no longer needed. This patch removes instances of this line from
manifest files. This makes some manifest files empty, so the patch
also removes the now-empty files.
Differential Revision: https://phabricator.services.mozilla.com/D8751
--HG--
extra : moz-landing-system : lando
We have to do this both for sweeping and when setting the current chunk. We
set the current chunk after sweeping so to have an effect when there's only
one chunk (the main reason for this code) we need to do this correctly then
also.
--HG--
extra : rebase_source : a7b3515588e4b7421d88cc855221b27c5d437038
These values were compared as floats, where there was no sagnificant
difference and the assertion failed.
--HG--
extra : rebase_source : 78540e23c113c781c515073f376ed5aa74322a07
