This is a quick-and-dirty port. It might be nice to replace
SpecialPowersObserver with the webextensions content script injection
system at some point, but that isn't practical right now (since WE experiments
cannot implement new APIs visible to content scripts).
MozReview-Commit-ID: GinCu3VcbWK
--HG--
rename : testing/specialpowers/bootstrap.js => testing/specialpowers/api.js
extra : rebase_source : 0faf7d21c8868c957ddc7fede0d56809f27dc161
extra : intermediate-source : ffb9ce93b92dd6396bfe038d3f6a8bcf929ec277
extra : source : cca596eadd0437dc75b75c119b6c7a405805f703
This class implements a shared memory key-value store that fits into a single
memory mapped segment. All of the runtime data for its instances are stored in
the shared memory region, which means that memory overhead for each instance
in each process is only a few bytes.
Importantly, the key and value strings returned by this class are also
pointers into the shared memory region, which means that once an instance is
created, its memory cannot be unmapped until process shutdown.
For the uses I intend to put it to, this is a reasonable constraint. If we
need to use it for shorter-lived maps in the future, we can add an option to
return non-literal dependent strings that will be copied if they need to be
kept alive long term.
MozReview-Commit-ID: 5BwAaDsb7HS
--HG--
extra : rebase_source : b472fe628018f88a2c4d6b3de4b7143aeca55e14
extra : absorb_source : 5cdeb568cfd2b4a5a767191402e699e61e653b3b
This class allows us to map a read-write shared memory region, and then safely
remap it read-only, so that it can be shared with sandboxed content processes.
MozReview-Commit-ID: 2PJMQgOwA4V
--HG--
extra : rebase_source : c556cabfa7d379a91dc9ef7171ac0a7d7d8fb32e
extra : absorb_source : e78e304ed95891c694050f79a0bb5d40d11ee884
This is a quick-and-dirty port. It might be nice to replace
SpecialPowersObserver with the webextensions content script injection
system at some point, but that isn't practical right now (since WE experiments
cannot implement new APIs visible to content scripts).
MozReview-Commit-ID: GinCu3VcbWK
--HG--
rename : testing/specialpowers/bootstrap.js => testing/specialpowers/api.js
extra : rebase_source : 8be131e80d95a6bf6e86c994fdfa40c14ba610eb
extra : source : cca596eadd0437dc75b75c119b6c7a405805f703
Currently, do-these-references-alias queries for Wasm global variable
accesses are handled incorrecty. We fail to identify the case where both
references are indirect (that is, imported) as possibly-aliasing. This can
lead to incorrect code generation in some pretty simple cases involving
globals, when compiling Wasm via IonMonkey.
This commit fixes that. It also adds clarifying comments to
MWasmLoadGlobalVar::congruentTo and MWasmLoadGlobalVar::valueHash pertaining
to equivalance-of-loaded-values assessments.
--HG--
extra : rebase_source : 3f77fa1fd0085ab1922b8eaf7cb2d9891bc6e390
This augments the Ref type patch by making the subtype test perform automatic
upcasts to prefixes. The prefixes are still quite strict; corresponding Ref
types must name the same underlying type and corresponding fields must have the
same mutability.
--HG--
extra : rebase_source : 43cc552e77f9e3f5d7f7b2fa761d956c9c61f149
extra : intermediate-source : bb1d37aa16dd0dbdf21c80e34156026693b898cf
extra : source : 2c8c0301cc33ca0af490629a999f2d2dd854d72f
The StructType and AstStructType machinery must retain the information about
field mutability (to be used by subsequent patches).
For StructType, I opted to create a StructField structure that holds the
information per field. This works well except when we (occasionally, not in
this patch) need an array of ValTypes for some existing functionality.
For AstStructType, I opted to keep the array of mutability flags separate from
the arrays of names and field types, because this was simplest.
In either case, we could do it the other way.
--HG--
extra : rebase_source : a99a2ff5619441f4d0d428fdf1890adef892d5aa
extra : source : 78d954331af90f6f81bd86595beef2c15952510f
We generalize ExprType and StackType in the same way as ValType, in
order to reduce the scope for error. (Intermediate solutions that
avoided this turned out to be too error-prone.) ExprType, StackType,
and ValType now share a representation of a TypeCode + reference type
index, called PackedTypeCode, but don't otherwise share much code -
ExprType is going away soon and StackType will change.
We then generalize many of the Ast nodes so that we can represent the
new types available in the binary and textual formats. This is
wrenching in the same way that generalizing ValType and ExprType was.
Finally we provide parsing, resolution, printing, and validation of
(ref T) where T is some structure type. This code should be general
enough to later expand it to array types.
The type calculus here is that (ref n) == (ref m) if n == m, ie, these
are nominally equivalent; the only new subtype relationships are that
(ref n) <: (ref n) and (ref n) <: anyref. If the subtyping of anyref
were to go away there's a small amount of work that would have to be
done to handle the polymorphism of ref.is_null.
--HG--
extra : rebase_source : 7a1a01d1f5624baeb29383a9ae6a5bdf03411181
extra : intermediate-source : dc8f0270e0e3932ba661a57496401d00903c9ba2
extra : source : 3c5da122b7034dae69d16ca9e577afb93cf7b2c1
As a tweak the wasm CG has decided to allow the special case where an i64 global is
created from JS with the default zero value, while we're waiting for BigInt and
more general i64 support. This amounts to removing the error we would otherwise
signal in this case.
--HG--
extra : rebase_source : 264c1907e0787f067cc954c98726733227e79a78
