The new output uses syntax with square brackets: {[Symbol.for("key")]: "value"}
This syntax is not yet supported in SpiderMonkey, but it is part of ES6 (see
bug 924688 or search the ES6 drafts for ComputedPropertyName).
--HG--
extra : rebase_source : 6976a1025c268aaed3462d900b83fa6a33515e78
Unfortunately, with symbols, the original goal of this code is apparently
impossible. For two unique symbols with the same description, short of doing
extra bookkeeping at run time, there's no ordering that's sure to be consistent
across runs. The new code orders all other symbols.
--HG--
extra : rebase_source : 0734906d046e577d4c7d65149ec688dd0b80e885
Object.keys, Object.getOwnPropertyNames, and for-in loops skip symbol-keyed
properties per spec, but Object.defineProperties sees them, and a future
Reflect.ownKeys API will need to be able to see them.
This patch changes the comments on JSITER_FOREACH and JSITER_KEYVALUE, but not
the behavior. The comments were just wrong.
--HG--
extra : rebase_source : f1ad99d416df8a8acef5598bef2cde4b72dcdb31
This patch also updates legacy direct proxies to cope with symbols. Uniform
behavior seems like the easiest thing to carry forward.
--HG--
extra : rebase_source : 5e5251c942e879a4440d7c0524343cf6fc744c7e
This is unnecessary now that object jsids no longer exist. Both string and
symbol jsids point only to GC things in the atoms compartment, which are safe
to pass to any compartment without wrapping.
--HG--
extra : rebase_source : 82c21e8474df05b1bb42c14d872c981205bbe879
With just this patch, there are not actually any symbol jsids flowing through
the system, just as there are not actually any object jsids. But a subsequent
patch (part 23) changes this.
This patch deletes some code in CTypes.cpp that is simply confused about how
element accesses work: Int64 and UInt64 objects were never actually converted
to object jsids, so the code being removed here was already dead code.
--HG--
extra : rebase_source : 86f421c6454344e76ce5219b7b1aed5c83b45f24
The contract of assertDeepEq(a, b) is that the assertion passes iff a and b
have the isomorphic heap graphs. Symbols, like objects, are treated as nodes in
this graph. So, for example, if a and b are distinct symbols, then [a, b] is
not deepEq to [b, b] because they have distinct graphs. There are three nodes
in [a, b]: the array, a, and b. There are only two nodes in [b, b]: the array,
and b.
--HG--
extra : rebase_source : 9415559bab9f0ed132dd49d3790892b3209fa77b
The spec defines this by way of a @@toPrimitive method. We fake it using a
JSClass::convert hook. (Once @@toPrimitive is implemented, convert hooks
can be removed entirely, but we need symbols first.)
--HG--
extra : rebase_source : c8c7ed3eead8bd79bb38b70f448ebb98c5b3d780
The test as-base-value.js is not testing symbols as property keys (which is
implemented in a later patch), but on the other side of the . operator: as
things that can have property accesses done to them, just like you can do
"name".length or (3.14).toString().
--HG--
extra : rebase_source : 3dac7660999bd021ec32c13985471e1608a29f64
The change in jit-test/tests/symbol/toString.js is that we now check that an
exception is actually thrown. Until this patch, stringifying a symbol did not
throw. (The test was mainly checking that we did not assert in Ion.)
No changes in Ion. If a symbol is being stringified, it's ok to be in a slow
path because that is going to throw anyway.
--HG--
extra : rebase_source : 9cf314dafa7392a20fee9d3b5acc4ad7fc1c5229
At present there is only one, Symbol.iterator, and it is not hooked up to
anything (this happens in bug 918828). ES6 defines 8 well-known symbols. Each
one is attached to a feature, so we'll add the symbols as we add features.
Symbol.create will appear when @@create semantics are implemented.
--HG--
extra : rebase_source : aab40a7487708c8bbd23dcfbe935ece1903d75ff
Trivial. Since symbols are always allocated in the atoms compartment and all
compartments are allowed to have direct references to them, Compartment::wrap
on a symbol is a no-op.
--HG--
extra : rebase_source : 2f51ff0b3870885de8c6ef6a82efa7398e17d5e8
Symbols are not yet supported as property keys at this point in the stack. The
work here is to pass symbol pointers around in Ion JIT code unboxed.
The baseline compiler doesn't need much new code. A few kinds of ICs need to
know all the primitive types.
--HG--
extra : rebase_source : 3addcd18e913e5879b0ee3700ecf9660b14b1e05
This exposes a new primitive type to scripts for the first time since
JavaScript first shipped in Netscape 2, over 13 years ago.
The tests focus on identity, equality, and being able to pass a symbol around
as a value. Of course the point of symbols is that they can be property keys,
but that will have to wait for a later patch in this series.
--HG--
extra : rebase_source : c22cf4b774cca8e7c9f6c757079e054a6eb0f307
