... where LLVM (32-bits toolchain) runs out of memory when compiling
gkrust.
--HG--
extra : rebase_source : f47ba34fddcb3913793781fd26cfa32293b5baf9
extra : histedit_source : 2f85d1864f963759bc97cb69b39648fb0d964578
- Embed vendored Rust dependencies into the source package.
- Don't use --freeze with Cargo in JS standalone builds: since all the Rust
dependencies are vendored in, it won't trigger an update of the toplevel
Cargo.lock file for a standalone build in the non-package build case.
--HG--
extra : rebase_source : 06704eb326aad36a870586694a99964ad7a4dbfa
extra : histedit_source : 1502d976bc12a3eed17efaaf5dd2d4f46d0b00d5
Also make sure to precise the panic behavior before compiling Spidermonkey and
its Rust dependencies, to be compatible with the Rust bindings which want to
unwind Rust code properly and not abort as Gecko does.
--HG--
extra : rebase_source : a15e42f2cbfe94bdcd2d66d101bbc39ca385ddce
extra : histedit_source : a6dd8e0d913b911564e01b34eb9bb78087d694b5
Some build flags are being passed by the build system: they're passed in a text
file called extra-bindgen-flags.in that's filled at configure time.
Other flags have to be inferred from the current target/host combination, in
Cranelift's build script directly. This is mostly cargo-culted from the
ServoBindings.toml file, and should probably be merged in the build system at
some point.
Some Windows-specific adjustments were needed to provide access to libclang for
bindgen support, by adding clang-cl to the plain Spidermonkey Windows builds.
--HG--
extra : rebase_source : 0bda40b1d1eb38c2657593f094c951013711d00a
extra : histedit_source : aad930a5f9099e299d385ae4de2deb81aed9b6d5
This introduces two new crates:
- jsrust, for standalone builds. This crate is compiled into a static library
libjsrust.a, which gets linked into the shared Spidermonkey library when it's
built, or into the static Spidermonkey library otherwise. This is just a
static library wrapping jsrust_shared below.
- jsrust_shared, for Gecko embedding. It just references other Rust
crates actively used in Spidermonkey. It is used to be embedded as part of
a new Rust dependency in Gecko (in gkrust).
--HG--
rename : js/src/wasm/cranelift/Cargo.toml => js/src/rust/Cargo.toml
extra : rebase_source : 84e440e3f669b73776653182cb7b006cc7febb10
extra : histedit_source : 3a67575ff6871b7dc3558c10a0251b73cedb090c
For now, we only allow one memory / one table, so we verify that the index,
if present, is zero, and then go on as before.
--HG--
extra : amend_source : 37d0084d17e8be857a28377a43ae9dc4b34018ea
Field names are unique within the module, so we handle them like
most other names.
--HG--
extra : amend_source : 0a09a6d8c9f0aa65af8015d08b24924efe7ba931
This code is a little messy since we define opcodes unconditionally but
switch on them conditionally. Cleaning up ifdefs in previous patches
uncovered brittleness here. This patch takes a principled approach:
we always test all cases, but whether we succeed with a classification
or fail with undefined opcode is hidden inside macros that are subject
to feature definitions.
--HG--
extra : amend_source : 47350a30cfa6737d868144e53ec7f8beea150524
Replace various custom data-types in JSScript interfaces with
mozilla::Span. This abstracts implementation details and supports
range-based for-loops. Underlying storage is unchanged, but this sets us
up to be able to more easily change it.
MozReview-Commit-ID: FDfIYsAxTA8
Error handling for LIRGenerator lets us defer handling until the end of
the instruction but this can result in tripping some sanity checks. Only
report the first error up to caller.
Differential Revision: https://phabricator.services.mozilla.com/D6979
--HG--
extra : moz-landing-system : lando
IonBuilder::jsop_setarg optimizes asm.js-style argument coercions
using JSOP_BITAND, JSOP_BITOR, or JSOP_POS. The optimization
assumes that bitwise operations always produce Int32 results, but
they may produce Value results due to BigInt-related changes in
bug 1490387.
I can be more granular if we want, by adding more ChromeOnly annotations for the
functions that we don't want to expose.
Differential Revision: https://phabricator.services.mozilla.com/D6530
--HG--
extra : moz-landing-system : lando
The new error is thrown if, for example, you try to create a ReadableStream via
the C++ API while streams are disabled.
Depends on D6553
Differential Revision: https://phabricator.services.mozilla.com/D6554
--HG--
extra : moz-landing-system : lando
I can't currently dedicate time to a breaking change to date parsing, so this
patch implements exactly what the previous code probably does already, but
without the undefined behavior.
Differential Revision: https://phabricator.services.mozilla.com/D6675
--HG--
extra : rebase_source : 9994d4afae95a0024d0d6fd6d9ad54b94cad1ddf
A C++ object that is exposed to JS can have its reflector used as a
key in a weak map. Because a weak map does not keep its keys alive,
this means that the reflector can be discarded if it has no other
references aside from the C++ object, which will in turn remove its
weak map entry. If the C++ object can be accessed again later from JS,
it will get a new reflector which will have no weak map entry. This is
bad because it means some internal implementation detail has resulted
in data loss that is visible to JS. (Side note: this is also an issue
for cross compartment wrappers, which is handled by another
mechanism.)
To fix this, we can preserve the wrapper of any DOM reflector used as
a weak map key. This ensures that the reflector and its C++ object
have the same lifetime. If a WebIDL object is not wrapper cached, that
means that it cannot be accessed via C++, so we don't need to preserve
the wrapper. This is currently implemented for nsISupports classes,
but not other classes. For non-nsISupports classes, it would throw an
error rather than silently fail.
My patch adds support for non-nsISupports cycle collected objects. It
turns out that the existing addProperty hook just does wrapper
preservation, so we just call it for cycle collected classes. This
does mean that if addProperty changes in the future to do something
else, this code will need to be changed.
I verified that this test fails if TryPreserveWrapper is changed to do
nothing besides return true in the non-nsISuports case.
Depends on D6197
Differential Revision: https://phabricator.services.mozilla.com/D6198
--HG--
extra : moz-landing-system : lando
