This is according to spec for the mozilla71 cycle, a follow-up will further adjust to spec.
- Add Intl.Locale as native C++
- Port Unicode BCP 47 locale identifier parser to C++
- Port language tag parser to C++
- adjust make_intl_data to generate the data
Based-on: m-c 1433303, 1570370
- turn each Intl object into a NativeObject subclass
- create them as PlainObject
- ensure correct type is passed in self-hosted code
- implement legacy constructor semantics for DateTime&NumberFormat
- store internals on object slot instead of JS WeakMap
Based-on: m-c 1328386, 1332604
Backported from Mozilla bug 1516742.
The .from* methods are going to depend on SameValueZero, which needs to be
visible to /dom. This patch provides the foundation for that.
This is the one I don't understand how it fixed the bustage. Why is it needed
to remove JS_PUBLIC_API..? It would seem counter-intuitive, but it wasn't...
The unsafeSet method is based on Jon Coppeard's part 2 patch for Mozilla bug
1306008. This is needed because of the use of unsafeSet in rekey() of
MovableCellHasher<JS::Heap<T>>
Based on Mozilla bug 1345177.
Changes from the original bug's patch:
- We don't have JS::CurrentThreadIsHeapCollecting, so let's use
trc->runtime()->isHeapCollecting() instead.
- Mozilla bug 1337117 renamed runtimeFromMainThread to
runtimeFromActiveCooperatingThread for Firefox 54, so let's use the former
Based on Mozilla bugs 1270140, 1504656, 1483545, and 1504334.
Took note of Mozilla bug 1379222 which changed GetPrototypeFromCallableConstructor
to GetPrototypeFromBuiltinConstructor.
There are many other changes I did myself since the initial implementation by
Mozilla wouldn't work with this codebase.
|entryCount| tracks -- in fast-to-check manner -- the number of entries in the hashtable. But to actually enumerate entries, we have to loop through all of |table|, checking for entries that are actually live. A live entry is indicated by a zero |hash| in the entry. The |memset| would properly zero that; removing the memset will not.
It's not entirely clear whether a memset that overwrites a lot of stuff but is maybe simpler, is faster than compiler-generated likely-SIMD code that zeroes out *just* |hash| fields in all the entries. But I am going to guess that SIMD is good enough. For now, we should just do the simple and thing: don't distinguish POD and non-POD, and know that the compiler is going to recognize that |mem.addr()->~T()| is a no-op when T is trivial. So with POD, the loop should degenerate to just zeroing |hash| at consistent offset, and SIMD will eat that up, and it can't be *that* different from the memset in performance (if it is at all).
