This is a complete rewrite of the interface while maintaining the same APIs.
Each ID is fully-contained within a single object, does not require a finalizer,
and is cheap to create.
Beyond using reserved slots, this code avoids using custom ClassOps, instead
preferring Symbol.hasInstance and eager constants.
One major change which occurred in this patch was the move from storing a nsCID
to storing the ContractID for JSCID objects. This eliminates the need for the
'refreshCID' method, and hopefully shouldn't have performance implications.
If we discover that there are performance problems there, we can look into
stashing the CID, and re-introduce 'refreshCID', despite its surprising
behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D2286
These two interfaces are effectively never used, so to avoid needing to support
ClassID2JSValue with the new implementation, I remove them entirely.
Differential Revision: https://phabricator.services.mozilla.com/D2285
This mostly consists of changes to the XPCComponents objects to avoid using the
implementation details, and instead use the API defined in part 1.
Differential Revision: https://phabricator.services.mozilla.com/D2284
This lets us get rid of the method 'initalize', which currently needs the
internal representation of JSCID.
This particular method is removed entirely in Part 9, and only exists to keep
intermediate states building & running.
Differential Revision: https://phabricator.services.mozilla.com/D2282
This should be mostly compatible with the original implementation. I tried to
simplify things here to just directly wrap and use JS objects, calling methods
on them. This eliminates the nsXPCConstructor type completely, replacing it with
a JSNative constructor with predefined READONLY | PERMANENT properties.
Differential Revision: https://phabricator.services.mozilla.com/D2280
This is the first part of hiding the implementation of nsIJSID behind the
interface added in Part 1, such that we can substitute that implementation out.
I had to make a couple of changes to fix the errors caused by the new behaviour
in GenerateQI.
Differential Revision: https://phabricator.services.mozilla.com/D2279
The new API tries to be more generic, taking and producing JS::Values. It also
supports creating the more specialized IID and CID types.
Differential Revision: https://phabricator.services.mozilla.com/D2278
This also adds a js::ClassOps variant, js::DefaultGlobalClassOps which can
be used in js::Class.
Depends on D11569
Differential Revision: https://phabricator.services.mozilla.com/D11570
--HG--
extra : moz-landing-system : lando
The first comment appears in ReadableByteStreamControllerPullSteps. It's OK to
delete it because we just asserted that there are no pending read requests
(step 3.a.).
The second comment appears in JS::ReadableStreamUpdateDataAvailableFromSource.
It's OK to delete this one because it's in the hasDefaultReader branch. Default
readers don't have read requests that care about the number of bytes available.
Differential Revision: https://phabricator.services.mozilla.com/D12111
--HG--
extra : moz-landing-system : lando
ReportArgTypeError is replaced with a new helper function template,
UnwrapAndTypeCheckArgument. The old function used the expression decompiler,
but that seems unhelpful here; the new code uses InformalValueTypeName on the
actual argument value.
Differential Revision: https://phabricator.services.mozilla.com/D11684
--HG--
extra : moz-landing-system : lando
Each patch in this stack deletes comments that are redundant with the new
naming convention.
In ReadableStreamTee_Cancel, we have a variable named `unwrappedReason` whose
purpose is to create a properly wrapped verison of `reason`. It's a little
vertiginous. But I think this is what the new convention demands and it's not
so bad.
Also in ReadableStreamTee_Cancel, step 4.c., we wrap `cancelResult`, which does
not have an `unwrapped` tag. This is because we switched realms between the
declaration of `cancelResult` and the line of code where we're going to use it.
I think this just means the convention is never going to make all correct code
obviously-correct and all wrong code obviously-wrong. Still an improvement.
Differential Revision: https://phabricator.services.mozilla.com/D11683
--HG--
extra : moz-landing-system : lando
This renames the other CreateReadableByteStreamController signature, since the
two seem different enough to warrant distinct names.
Differential Revision: https://phabricator.services.mozilla.com/D11680
--HG--
extra : moz-landing-system : lando
They already do, as it's impossible for content to get hold of a stream with no controller,
which is the only kind of object our existing code would accept. But the spec is now more
direct, and the code should match it.
Differential Revision: https://phabricator.services.mozilla.com/D11679
--HG--
extra : moz-landing-system : lando
In the code generator function, we assume we have a temp if a known constant is
a non-negative power of two. But lowering only checked for power of twos
independently of their sign, so this was incorrect. This patch syncs them up on
both ARM32 and x86.
--HG--
extra : rebase_source : 3d4fb428892d67249af73dbdfe06ff7d43e7c02a
extra : histedit_source : cf49ed802cc47ae38859c76da63c279959b9635d
A lazy stub could generate CodeLabels on x86, because of a constant NaN
generated for the entry's epilogue that ended up in a constant pool. We need to
actually bind these code labels in general.
Differential Revision: https://phabricator.services.mozilla.com/D12052
--HG--
extra : moz-landing-system : lando
... to take into account that table entries are always two-word sized. Also
adds an assertion that tables are table of functions, since Cranelift doesn't
handle anyref tables yet.
Differential Revision: https://phabricator.services.mozilla.com/D11996
--HG--
extra : moz-landing-system : lando
web-platform-tests gets its test list from a manifest file that's
generated from the content of the tests. Unfortunately generating this
manifest is slow, so it's unreasonable to create it from scratch for
every test run. Until recently the generated manifest was kept
in-tree, which was suboptimal in a few ways:
* The manifest tended to get out of sync with the actual source
* The large json file caused problems for tooling including source
control and the review frontends.
We previously switched `mach wpt` to download a manifest on demand and
apply an incremental update. However this work missed the usage in
jstests.py. This continued to use the increasing outdated in-tree
manifest, which causes a number of problems
* It doesn't have an up-to-date list of tests
* It blocks removing that file
* It blocks landing various optimisations to make updating the
manifest faster.
This patch fixes jstests.py to use a downloaded manifest. Unlike the
tests run through a mach frontend jstests.py doesn't know where the
objdir is, so it's hard to work out where to download the
manifest. This patch adopts a heuristic approach; if the path to the
jsshell looks like <root>/dist/bin and <root>/_tests exists, we assume
it's a gecko-like objdir and use <root>/_tests/web-platform/ for the
manifest; otherwise we just put it into the system tempdir.
Because the manifest has to be updated on startup, this patch causes a
startup time regression, but this will be considerably reduced by the
work in Bug 1497898 for which this is a prerequisite.
Differential Revision: https://phabricator.services.mozilla.com/D11667
--HG--
extra : moz-landing-system : lando
André Bargull
Jon Coppeard
Andreea Pavel
Cosmin Sabou
Nika Layzell
Philip Chimento
Luke Wagner
Gurzau Raul
Jason Orendorff
Benjamin Bouvier
Bogdan Tara
Mike Hommey
Narcis Beleuzu
Csoregi Natalia
Margareta Eliza Balazs
Rob Wu
arthur.iakab
Brian Hackett
Ted Mielczarek
Tom Schuster
James Graham