While not directly related to the others from this bug, I stumbled upon
this while looking why there were references to MOZ_DMD in
js/src/old-configure.in while it was never set there.
MOZ_DEMANGLE_SYMBOLS is tied to MOZ_STACKWALKING, which is not set in
js/src/old-configure.in.
MOZ_COMPONENTS_VERSION_SCRIPT_LDFLAGS is specific to building XPCOM
binary components, which there are none of under js/src.
old-configure and js/src/old-configure interestingly didn't handle both
the same way. But vtune support is only actually implemented in js/src,
so only the rules from js/src/old-configure matter (nothing was
enforcing the decistion from old-configure to js/src/old-configure), and
this is what is implemented here.
Its value is always 1, and never used. Even when there were different
possible values back before bug 627277 (5 years ago), it was not used.
In fact, it hasn't been used since bug 298044 (more than 10 years ago).
Its value is always 1, and never used. Even when there were different
possible values back before bug 627277 (5 years ago), it was not used.
In fact, it hasn't been used since bug 298044 (more than 10 years ago).
The SIMDToLane() function in the SIMD.js specification uses ToNumber() to
coerce lane index arguments to a number before checking the the index is an
integer in range.
Add an ArgumentToLaneIndex() function to SIMD.cpp that implements the same
semantics. This function throws a RangeError if the coerced argument is not
integral or out of range.
Update tests to match the new semantics. The differences are:
- More values are accepted as lane indexes (null, true, false, "5.0", ...).
- A TypeError is only thrown if ToNumber fails. If the argument can be coerced
to a number, a RangeError is thrown if other checks fail.
Fix the testShuffleForType() test in ests/ecma_7/SIMD/swizzle-shuffle.js which
should have been calling `shuffle` but was calling `swizzle`.
MozReview-Commit-ID: 7w5KhWwKmeF
--HG--
extra : rebase_source : 1bedc9df4c157080be53b356c7f31f7588c3bceb
As part of unblocking building with VS2015u1 in automation, I'm mass
disabling compiler warnings that are turned into errors. This is not
the preferred mechanism to fix compilation warnings. So hopefully
this patch never lands because someone insists of fixing the underlying
problem instead. But if it does land, hopefully the workaround is
only temporary. That being said, the warnings this patch masks are
in an included ICU header, which is a 3rd party project. So our hands
appear tied.
MozReview-Commit-ID: FHzp6v5yUKG
--HG--
extra : rebase_source : cd22e81394ce7e537fb8cd93a3ae62dcb99b8567
And forbid SIMD arguments for the moment, as FFI SIMD arguments should be
either objects (interpreter) or unboxed registers (ion).
MozReview-Commit-ID: HWXYiFfmK51
--HG--
extra : rebase_source : f3e278048a2901a734e4c7592615a0801eb2cb15
