The mutability of the imported value must match the mutability of the
import declaration.
If an imported value is provided as a number constant and not a
WebAssembly.Global, then it is implicitly immutable.
Drive-by fix: We test for non-number imports before testing for i64.
--HG--
extra : rebase_source : 0a8bfedf8208aca4219370ecdeb56c930d03d1c6
We'd really like the LiveSavedFrameCache to be able to assert that, if a frame
has its hasCachedSavedFrame bit set, there is indeed a cache entry for it (if
the cache hasn't been cleared completely for a compartment mismatch). See the
explanation of LiveSavedFrameCache in Stack.h, and the comments in
LiveSavedFrameCache::find.
Sometimes we do find a cache entry for the frame, but execution in that frame
has progressed to a different source position since we cached it, so the
SavedFrame in that cache entry isn't useful. When this occurs, we used to simply
pop the cache entry, and report a miss: although this did create a situation
where a frame with its bit set had no cache entry, that was only temporary: we
would push a new entry for the frame as we build the new SavedFrame chain.
Unless, of course, SavedFrame construction encounters an OOM and the whole
process aborts early.
This patch clears a frame's hasCachedSavedFrame bit when we report a cache miss
due to a pc mismatch. Under normal circumstances, the frame will soon be cached
again and its bit re-set. If an OOM does occur, the absence of the cache entry
is accurately reported.
--HG--
extra : rebase_source : 5e980e5732b7fd5ff1dd6a68c1a49a1c538010c6
extra : source : 2ed6d9d910b0f3dd24e163f17e3a70d327286582
This entails implementing corresponding methods on each variant of
FramePtr::Ptr.
--HG--
extra : rebase_source : 3b810cd4d3aa78d014f830acbf2d6e6794694415
extra : source : 014fdec944a9e82fd74e7ff4644cb4f9e96076c2
OOM tests often depend on invoking a function repeatedly, failing a different
allocation each time. Flushing the caches helps ensure consistent behavior from
one invocation to the next.
--HG--
extra : rebase_source : 0bf4a46c7c3e0bceb0fe77bbf96e422558a988c4
extra : source : 1a11067ab1e6b62602b79081e3208dcad31807bd
This crate contains a parser generator as a Rust crate. The parser generator is used to generate
BinSource-auto.h, BinSource-auto.cpp, BinToken.h. As of this changeset, to limit yak shaving,
the parser generator is not part of the build system. Making it part of the build system
is delegated to bug 1439645.
MozReview-Commit-ID: 1lODDSIsz8W
--HG--
extra : rebase_source : 2b09675167c12e33f5951ea00dc6df54dad11832
This patch is a nearly complete reimplementation of BinASTReader, with the following changes:
- Files BinToken.h, BinSource-auto.h (new), BinSource-auto.cpp (new) are now autogenerated by the generator in js/src/frontend/binsouce from the webidl specifications of BinAST and a small
configuration file.
- Optional fields have been removed. Rather, some specific fields may, if so marked in the specifications, contain a Null constant.
- `hasDirectEval` is now checked for consistency (NOT completeness).
- `varDeclaredNames` is now checked for consistency (NOT completeness).
- `lexicallyDeclaredNames` is now checked for consistency (NOT completeness).
- `parameterNames` is now checked for consistency (NOT completeness).
- `capturedNames` is NOT checked.
- Atoms read are now properly expected to be UTF8.
This patch does not implement the entire specifications, but should implement most of ES5. In particular, it is sufficient to parse the source code of:
- Facebook;
- jQuery;
- mootools;
- Underscore;
- Backbone;
- Angular.
MozReview-Commit-ID: HwkVB5dliZv
--HG--
extra : rebase_source : fd7e068343e2af8926c5185e7199ea110a5149bc