If we cannot display all search engines then we want to show a smaller number so that the last one is
cut-off (we only display half of it). The previous version did not calculate the next smallest half
correctly: Instead of displaying 3.5 engines if we have space for 3.7 engines, we only displayed 2.5.
MozReview-Commit-ID: KfopL9td3ba
--HG--
extra : rebase_source : 22534e56a0b9668921fc7bc0d5c2f874823645ed
MozReview-Commit-ID: KFlaQoeGPRc
* I guess this has to be uplifted to aurora and included in the aurora->beta
merge
--HG--
extra : rebase_source : eb97b061f193e0f6d976ea374a3ed2677435520b
extra : amend_source : 843c4791f09dc39e21499dd1782614b2c5442b7e
Add better test coverage of boolean SIMD constructors with insufficient
arguments.
Add better test coverage of 8x16 and 16x8 constructor calls with missing args.
Fix a crash caused by a missing bool-to-int conversion before a boolean splat
when inlining a boolean constructor.
Fix a crash in the foldsTo method for boolean splats. The 8x16 and 16x8 booleans
were not implemented.
MozReview-Commit-ID: 71kjDpfw84h
--HG--
extra : rebase_source : d0d2f859f8daee3d9c50dbdc971c92b4a60a8543
While the casts being changed in this patch are correct as they are,
other functions near these use uintptr_t. For consistency's sake, it
seems better to use uintptr_t everywhere.
clang complains that it's unable to instantiate this template because
the functions being passed as arguments are MOZ_JNICALL, while the
actual parameter to the function has no such attribute. Adding the
attribute makes everything line up.
clang complains about specializations of NativeStubImpl not being able
to see the private constructor of ProxyNativeCall. While
ProxyNativeCall includes a friend declaration for NativeStubImpl, it's
not obvious *which* NativeStubImpl is being friended, as NativeStubImpl
hasn't been forward declared and exists in a completely separate
namespace. Forward declaring NativeStubImpl and adjusting the friend
declaration makes everything more correct.
clang complains that a constexpr definition of methods[] cannot refer to
members of the incomplete Impl template parameter, and rightly so.
Making these const is sufficient for our purposes, and that enables us
to move the declaration outside of the class, where it will be
instantiated lazily (presumably at the point when |Impl| is a complete
class definition). We also need to declare the length of methods[], as
other parts of the code require knowing the length of methods[] at
compile time.
String.prototype.contains was removed from Firefox 48 completely after
it was renamed to String.prototype.includes. The test includes a
call to .contains() which is triggered whenever random JavaScript
error occurs during the test (hence the intermittency).
MozReview-Commit-ID: 7nbRm94JM7O
--HG--
extra : rebase_source : e969bc1ad46120509deec31066ea63ebbb7de9c9
We had two potentials rounding issue occurring. The one causing the problem is that adding an int64 with a float is a float, and would be limited to 24bits mantissa.
The other, could be that rounding would occur if the segment duration was over 16s long, as that too would exceed the representation range as we using microseconds representation internally.
MozReview-Commit-ID: FyBTGvfg25I
--HG--
extra : transplant_source : %D0%14u%E3%1E%C6%D2%FC4%A4%2B%C0%20k%05%E8%90qz%2B
This test was removed as part of commit 2a7dbc0411d1, but we still try to run
it.
MozReview-Commit-ID: HfFkugGz2vI
--HG--
extra : rebase_source : 6073292e18b39cd54c976322c89e2371a27d3d24
extra : amend_source : 3b918c333ef0e07a07aa0bc3d957ea3ac65d79ad
