This aligns with the triplets used by clang/llvm. Technically, this
won't break iOS builds still using -darwin triplets until we move
MOZ_IOS_SDK to moz.configure and actively reject non iOS targets with
the iOS sdk.
Also allow to distinguish iOS and OSX with target.os.
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
The behavior of ::BrowserTabsRemoteAutostart() shouldn't change, meaning that every result remains the same. The new getter can be accessed by JS through Services.appinfo.multiprocessBlockPolicy
MozReview-Commit-ID: 62PpbeJcMCI
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. But the warning
occurs in third party code, so my hands are tied.
MozReview-Commit-ID: A0UF2RHJzVo
--HG--
extra : rebase_source : 3fc5300f6f67274162f4d65fd83eb9c18b4bf716
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
Previously, Windows toolchains and related dependencies (SDKs, etc)
were installed on Windows builders by people responsible for
maintaining those machines.
This commit takes a step in a new direction. We introduce a
script (complete with documentation) that can produce a zip
archive (or any archive format if people want to implement
support) of the toolchain files. Basically, you install
Visual Studio 2015 Community, run the script, and produce
a self-contained zip file containing everything from Microsoft
you need to build Firefox. With a copy of this archive and
an installation of MozillaBuild, it is possible to build
Firefox on a fresh Windows installation. No time-consuming
Visual Studio installation needed.
The goal is to upload these archives to tooltool and have
our Windows builders download and extract them at run-time.
At which time, we can remove all the other Visual Studio
and SDK files from builders because they don't need to be
baked into the image.
We may find tooltool's caching isn't good enough and we have
to more aggressively caching the standalone toolchain files.
But that is a problem for another day. Whatever happens,
we'll need the functionality in this script to produce
a self-contained archive of the toolchain.
There are certainly files in the produced archive that aren't
needed. I think perfect is the enemy of done and we can prune
the archive over time, if wanted.
MozReview-Commit-ID: EckEK1a6vA3
--HG--
extra : rebase_source : c328be792b2bfb4b3cb8acb50e4868277cb59974
extra : source : 4c980771e574e899a1b05319ad11fb6cffb00087
Make query events fail (including when caching selection) if the queried
content root is different from what we expected.
Also, introduce a fix-up to the selection fix in test_imestate.html.
