Creates a level of indirection to encapsulate the compilation
parameters (mode, tier, debug, gc-enabled) so as to allow their
computation to be delayed. This centers on the new struct
CompilerEnvironment, defined in WasmValidate.h.
After this change, compiler selection is driven by the presence of the
gc-feature-opt-in section. We finalize the values in
CompilerEnvironment after having parsed that section. (That parsing
is still under #ifdef.)
--wasm-gc is still used as a higher-level control; if it is not
present there will be no gc support at all. But once we remove that
flag, very little will change here; all code that reads that flag can
instead pass HasGcTypes::True, and compiler selection will be entirely
driven by the presence of the opt-in section.
There are a few too many uses of HasGcTypes::False here; most of these
will disappear along with the --wasm-gc flag.
--HG--
extra : rebase_source : cbbc09dc7b1ae7777b66c8ba4b1c39c3e4195c46
This enables the following extra rules over the current configuration:
- for-direction
- no-compare-neg-zero
- no-new-symbol
- no-this-before-super
Other rules that are in eslint:recommended but not in our configuration are turned off for now.
Differential Revision: https://phabricator.services.mozilla.com/D4944
--HG--
extra : moz-landing-system : lando
Another option is to allow same-compartment realms here, but this seems simpler and safer (to ensure we don't leak any information in document.domain cases or if we ever change from CPO to something else). A principals check is probably not worth the complexity.
Differential Revision: https://phabricator.services.mozilla.com/D4868
--HG--
extra : moz-landing-system : lando
We introduce a new numbered section which must be the first section in
the .wasm file if it is present at all. This section, GcFeatureOptIn,
carries the version number of the GC feature the module wants to opt
in to.
During validation we signal an error if we can't satisfy the
requirement; and we signal errors for all the GC feature aspects
(anyref, ref, struct, and all the ref-type instructions) if no opt-in
section was present.
This patch does not affect how we generate code for stubs; that code
is controlled by the --wasm-gc flag, as it is module-independent.
This patch also does not change how we choose the compiler; that is
still based on --wasm-gc. But once --wasm-gc disappears we will be
using the opt-in section to control compiler selection until Ion can
support the GC feature.
Currently the only supported GC feature version is 1. As the engine
evolves to accomodate new versions we will accept old version numbers
provided the engine remains completely backward compatible. (We can
also provide version-triggered backward compatibility but I question
the utility.)
--HG--
extra : rebase_source : 65f5af647d851beadd4c743821f4546abe6e8b3e
Creates a level of indirection to encapsulate the compilation
parameters (mode, tier, debug, gc-enabled) so as to allow their
computation to be delayed. This centers on the new struct
CompilerEnvironment, defined in WasmValidate.h.
After this change, compiler selection is driven by the presence of the
gc-feature-opt-in section. We finalize the values in
CompilerEnvironment after having parsed that section. (That parsing
is still under #ifdef.)
--wasm-gc is still used as a higher-level control; if it is not
present there will be no gc support at all. But once we remove that
flag, very little will change here; all code that reads that flag can
instead pass HasGcTypes::True, and compiler selection will be entirely
driven by the presence of the opt-in section.
There are a few too many uses of HasGcTypes::False here; most of these
will disappear along with the --wasm-gc flag.
--HG--
extra : rebase_source : d2c2bd01309124caaa66f13564be2bcf24f34946
This allows JS callers and C++ callers to both create and consumer iterators
in their preferred style, while still presenting the appropriate interfaces to
callers in the other language.
When a C++ caller requires an nsISimpleEnumerator from an XPCWrappedJS object,
if that class does not already have a QueryInterface method, it is assumed to
be a JS enumerator, and an appropriate wrapper is created. JS callers who wish
to implement nsISimpleEnumerator manually, or opt out of the automatic
conversions, may implement a QueryInterface method, which automatically opts
them out of this behavior.
Differential Revision: https://phabricator.services.mozilla.com/D4290
--HG--
extra : rebase_source : eb61ee725a8c67e3e7f5b22d9aef9baa0cde1955
Summary: It is currently quite difficult to debug minified scripts. The JitSpew and profiler used to display only line numbers, so all of the output would be emitted as "script:1". Column number information is now collected by the gecko profiler as of bug 785922. The JitSpew should also emit column numbers so that it's easy to line up with the profiler output.
Reviewers: mgaudet
Reviewed By: mgaudet
Subscribers: jandem
Bug #: 1485738
Differential Revision: https://phabricator.services.mozilla.com/D4677
--HG--
extra : source : 3f831b709e370b14ccf9f06508760633cd6b312a
Summary: It is currently quite difficult to debug minified scripts. The JitSpew and profiler used to display only line numbers, so all of the output would be emitted as "script:1". Column number information is now collected by the gecko profiler as of bug 785922. The JitSpew should also emit column numbers so that it's easy to line up with the profiler output.
Reviewers: mgaudet
Reviewed By: mgaudet
Subscribers: jandem
Bug #: 1485738
Differential Revision: https://phabricator.services.mozilla.com/D4677
--HG--
extra : rebase_source : b88732f8eccbbe712d3f42fc79b6c8019d294991
extra : histedit_source : 8d23b4b62549462444d267ba695a878a04ff896d
When an XPC wrapped JS object returns an object from a property or function
which is expected to return a given interface, we create a wrapper for that
interface regardless of whether the object has a QueryInterface method which
claims to support it. For the nsISimpleEnumerator enumerator case, the check
for that existing wrapper comes before the check for the nsISimpleEnumerator
special casing, which breaks automatic conversion in those cases.
This patch moves that check just before the check for the existing wrapper,
and just after the nsIPropertyBag special casing, which has similar semantics.
Differential Revision: https://phabricator.services.mozilla.com/D5335
--HG--
extra : rebase_source : 2201063455a2434cfa0c3c470f668fefa8528f4b
We introduce a new numbered section which must be the first section in
the .wasm file if it is present at all. This section, GcFeatureOptIn,
carries the version number of the GC feature the module wants to opt
in to.
During validation we signal an error if we can't satisfy the
requirement; and we signal errors for all the GC feature aspects
(anyref, ref, struct, and all the ref-type instructions) if no opt-in
section was present.
This patch does not affect how we generate code for stubs; that code
is controlled by the --wasm-gc flag, as it is module-independent.
This patch also does not change how we choose the compiler; that is
still based on --wasm-gc. But once --wasm-gc disappears we will be
using the opt-in section to control compiler selection until Ion can
support the GC feature.
Currently the only supported GC feature version is 1. As the engine
evolves to accomodate new versions we will accept old version numbers
provided the engine remains completely backward compatible. (We can
also provide version-triggered backward compatibility but I question
the utility.)
--HG--
extra : rebase_source : 5fac967236009019e4588226182706ca0543801f
This gcc 4.8.2 workaround (from bug 942421) is no longer needed because Firefox currently requires gcc 6.1 or later (as of bug 1444274).
--HG--
extra : source : cdc1d262eccb9d5fcd8f89e7514abc625e61c185
extra : histedit_source : e42d518cf586af1bdc45636541d5e136a2c2bfb8
We move the XPConnect() singleton accessor to nsIXConnect to make it available for consumers outside of XPConnect. Most of the consumers of the singleton accessor just need the nsIXPConnect public interface, except for the IsShuttingDown() member which this patch adds to nsIXPConnect as well.
Differential Revision: https://phabricator.services.mozilla.com/D5151
This moves all the node-specific reporting to nsIDocument.
OrphanReporter delegates all the reporting to that and then returns the sum of
all sizes, which is not ideal but was pre-existing.
Also, I moved the main mStyleSheets size reporting to DocumentOrShadowRoot for
it to be shared between document and ShadowRoot.
I'll add memory reporting for the computed stylesheet maps and such in the
ShadowRoot in a followup.
I went through all the XBL bindings, though it seems I could just use
GetBindingWithContent(), since according to:
https://searchfox.org/mozilla-central/rev/55da592d85c2baf8d8818010c41d9738c97013d2/dom/xbl/nsXBLBinding.cpp#615
We don't allow multiple bindings to contribute anon content. Anyway it was the
same amount of code...
Differential Revision: https://phabricator.services.mozilla.com/D4433
--HG--
extra : moz-landing-system : lando
For the time being, we do not want to expose struct types outside of
the module where they are defined, and so there must be restrictions
on how functions and global variables that traffic in struct types can
be used.
At the same time, intra-module uses of functions and globals that use
struct types must be allowed to the greatest extent possible.
Terminology: A function that takes a Ref parameter or returns a Ref
result is "exposed for Ref", as is a global of Ref type. Anyref is OK
though, in all cases.
To keep it simple we have the following restrictions that can all be
checked statically.
- Exported and imported functions cannot be exposed for Ref.
- If the module has an exported or imported table then no function
stored in that table by the module (by means of an element segment)
can be exposed for Ref.
- If the module has an exported or imported table then no
call_indirect via that table may reference a type that is exposed
for Ref.
- An exported or imported global cannot be exposed for Ref.
Conversely,
- If a module has a private table then it can contain private
functions that are exposed for Ref and it is possible to call those
functions via that table.
- If a module has a private global then it can be exposed for ref.
Note that code generators can work around the restrictions by instead
using functions and globals that use anyref, and by using downcasts to
check that the types are indeed correct. (Though the meaning of
downcast will change as the GC feature evolves.)
All the code implementing the restrictions is under an #ifdef so that
we can easily find it later; all the test cases testing the
restrictions are in a separate file. Few existing tests needed to be
adapted, and none substantially.
--HG--
extra : rebase_source : 89fbbf9524dc02f627018d11861df3ef91de851b
Previously we would unconditionally set the .external flag on a table
if it had an element segment, but we should only do this if the table
is initialized with an imported function and so may contain functions
from multiple instances.
--HG--
extra : rebase_source : b7712cedce26749768838f7213bf1574ef5baf48
And also fix a build issue with the pre-declaration of ReadOnlyCompileOptions
in vm/TraceLogging.h;
--HG--
extra : rebase_source : bb17c13f370c1cef50f09370f4a5b5055dced909
The 'x' prefix makes it clearer that these are infallible.
A couple of nsJSID methods are now also infallible.
--HG--
extra : rebase_source : fcce44a00212d6d341afbf3827b31bd4f7355ad5
There are surprisingly many of them.
(Plus a couple of unnecessary checks after `new` calls that were nearby.)
--HG--
extra : rebase_source : 47b6d5d7c5c99b1b50b396daf7a3b67abfd74fc1
BFD ld's --build-id means --build-id=sha1, but with lld it means
--build-id=fast. Both support the explicit --build-id=sha1, so use that.
Gold supports --build-id=sha1 too.
ld64, used for mac builds doesn't support neither --build-id=sha1 nor
--build-id.
This makes it much easier to update existing consumers of
XPCOMUtils.enumerateCategoryEntries to use the category manager directly.
It also, unfortunately, requires updating existing category manager consumers
to use the Services getter in order to avoid ESLint errors.
Differential Revision: https://phabricator.services.mozilla.com/D4278
--HG--
extra : rebase_source : fb9fd9b21db80af472ff6250a2e9a35e8d538147
This patch switches from GeneratorObject::finalSuspend to setClosed in order to
dodge an assertion in finalSuspend that the Generator state machine is
transitioning along an expected edge. The way the Debugger manipulates
Generator state is decidedly unexpected, from the perspective of the normal
rules, and we've decided to accept that.
The simulator uses a protection area instead of guard pages. Increase
the size of this protection to be larger than worst-case frame size for
EnterJit trampoline.
--HG--
extra : rebase_source : fe05738f67cc25530953d6eb16e5fc1221470691
These functions incorrectly passed sizeof(T) instead of 1, so we would allocate sizeof(T) * sizeof(T) bytes instead of sizeof(T) bytes. This was used for PcScriptCache where we would allocate a few extra megabytes due to this bug. The patch changes PcScriptCache to use UniquePtr + MakeUnique.
Differential Revision: https://phabricator.services.mozilla.com/D4343
--HG--
extra : amend_source : e9e3e906ac649a4b05d91c10e60bc10bc858fb98
For the same reason as previous commit, the code clang generates for
~AutoOutputRegister when inlined in CacheIRCompiler::emitArrayJoinResult
makes valgrind unhappy. The reason is that TypedOrValueRegister contains
a union with two types of different sizes, where clang makes the code do
a check against the larger variant before validating the union tag says
that's the type in use, and that doesn't go well under valgrind when the
union value was set for the smaller variant.
One way to fix this is to make the TypedOrValueRegister constructor fill
the uninitialized bytes of the union, but it also appears that the types
used in the union, as well as the union tag itself, are larger than they
actually need to be:
- AnyRegister::Code is a 32-bits integer representing a register number,
when no supported platform has more than 254 registers (accounting for
AnyRegister::Invalid),
- MIRType is a 32-bits integer (enum, actually) representing values that
are all below 256.
Changing only the former would make valgrind happy, avoiding the
uninitialized bytes being tested against in ~AutoOutputRegister, but it
was too tempting to do MIRType as well.
clang likes to transform conditions like:
if (A && B)
into
if (B && A)
where B might be undefined when A is true (or variants of the above with
! and ||, or split between multiple ifs). This doesn't go well with
valgrind, although it's valid (albeit seemingly convoluted).
In both cases fixed here, the condition A involves calling a function
with a pointer to a variable on the stack that may or may not be filled
by the function call, and the condition B checking the value of said
variable.
This allows JS callers to automatically get the correct types during
interation, without having to explicitly specify them.
Differential Revision: https://phabricator.services.mozilla.com/D3728
--HG--
extra : rebase_source : b708f382d8ea571d199c669bfed5b5a7ca9ffac4
extra : histedit_source : 7df6feb82088c8a5ca45dc28fe4d2b852c177fee
This patch allows us to define methods or getters/setters for any of the
current set of well-known symbols. Those are defined by adding the [symbol]
attribute to a method:
[symbol]
Iterator iterator();
which causes the method to define a property with the well-known symbol which
matches its method name (Symbol.iterator, in this case).
Due to the implementation details of the XPIDL parser, this currently does not
support defining a non-symbol function with the same name as a symbol
function:
[symbol]
Iterator iterator();
[binaryname(OtherIterator)]
Thing iterator(in nsIDRef aIID);
throws for a duplicate method name, even though there is no actual conflict.
Differential Revision: https://phabricator.services.mozilla.com/D3724
--HG--
extra : rebase_source : 1385e2da93113306730f7c087fe7385dbe668e91
extra : histedit_source : 3afd9fe38e7cbddc5576c2bd1673496dd623e489