Bug 1368932 removed MOZ_STATIC_ASSERT_VALID_ARG_COUNT because it didn't
actually work for large numbers of arguments. But it was kind of useful
for macros that expand to something broken when they are given no
variadic argument at all.
Now that we have a macro that doesn't require tricks to count empty
arguments lists, however, we can use straightforward static_asserts
instead of a generic macro, which has the side effect of providing more
context in the error message.
--HG--
extra : rebase_source : 223f85c2c5cc7b3fa8c584b70bb084784fb5764a
In a couple places, MOZ_PASTE_PREFIX_AND_ARG_COUNT is used to only count
the number of arguments, we can now use MOZ_ARG_COUNT directly for that.
--HG--
extra : rebase_source : 1064e4cc231863dc4aff83ee6bc90d318b4be418
These annotations aren't doing anything useful. The important thing with
the PseudoStack is that, during pushes, the stack pointer incrementing happens
after the new entry is written, and this is ensured by the stack pointer being
Atomic.
The patch also improves the comments on PseudoStack.
--HG--
extra : rebase_source : 100f8a5e4b750c15fac66175550c4c284a141f16
This reduces duplicate code by handling promise chaining in one place.
MozReview-Commit-ID: 474T5hvf9oM
--HG--
extra : rebase_source : b8de5bad5597234654d476b93c0c89abc5215073
extra : intermediate-source : b0f3d3fef28646c31c87acfbfbf36ec9329e7a6c
extra : source : 89aab3206558922271aff1d611f029aed3910acf
This patch fixes InvokeCallbackMethod() which should return null
if promise-chaining is not supported.
Before this patch, it could return non-null if one of the resolve/reject callbacks
returns a MozPromise while the other not.
MozReview-Commit-ID: 7YKNvRKEHQx
--HG--
extra : rebase_source : 6429d9eef35efa0128e8b5967097850e6f4a4325
extra : intermediate-source : 6f73de7d2d5fb01be19fdf7d7037b506425eab18
extra : source : a1849e24b09b0b4e986ffaef14d2602541c1c6e8
In TSF mode, application should retrieve messages with ITfMessagePump::GetMessage() or ITfMessagePump::PeekMessage() since TSF/TIP may handle the message before or after the host application handles it.
This patch rewrites the API users with WinUtils::(Get|Peek)Message() which use ITfMessagePump if it's available.
MozReview-Commit-ID: LwHIgp7SxLH
--HG--
extra : rebase_source : aa5750af9812f9b107c29546cbee6f9eede6ebfa
This reduces duplicate code by handling promise chaining in one place.
MozReview-Commit-ID: 474T5hvf9oM
--HG--
extra : rebase_source : b8de5bad5597234654d476b93c0c89abc5215073
extra : intermediate-source : b0f3d3fef28646c31c87acfbfbf36ec9329e7a6c
extra : source : 89aab3206558922271aff1d611f029aed3910acf
This patch fixes InvokeCallbackMethod() which should return null
if promise-chaining is not supported.
Before this patch, it could return non-null if one of the resolve/reject callbacks
returns a MozPromise while the other not.
MozReview-Commit-ID: 7YKNvRKEHQx
--HG--
extra : rebase_source : 6429d9eef35efa0128e8b5967097850e6f4a4325
extra : intermediate-source : 6f73de7d2d5fb01be19fdf7d7037b506425eab18
extra : source : a1849e24b09b0b4e986ffaef14d2602541c1c6e8
Manifest entries can contain flags, one of which allows to match on the
os running Gecko. The match is performed against the value returned by
nsIXULRuntime.getOS, which itself comes from the build-system's
OS_TARGET.
In practice, this means that things like os=WINNT, os=Darwin,
os=Android, os=Linux are valid filters, but the latter is too specific,
and most of the time, one would want something that is "any OS but
WINNT, Darwin, Android", which can't be expressed with manifest entry
flags (there is no "and" for them, only "or").
For convenience, we add the keyword "LikeUnix", which has that meaning.
--HG--
extra : rebase_source : faf3986d2a4361d12a512752e15e81270be224ef
Manifest entries can contain flags, one of which allows to match on the
os running Gecko. The match is performed against the value returned by
nsIXULRuntime.getOS, which itself comes from the build-system's
OS_TARGET.
In practice, this means that things like os=WINNT, os=Darwin,
os=Android, os=Linux are valid filters, but the latter is too specific,
and most of the time, one would want something that is "any OS but
WINNT, Darwin, Android", which can't be expressed with manifest entry
flags (there is no "and" for them, only "or").
For convenience, we add the keyword "LikeUnix", which has that meaning.
--HG--
extra : rebase_source : ce2549fab96cb1df3f984e43cb08413cad49479e
This patch is originally from :baku and updates the seek behaviour of
nsMulitplexInputStream. This fixes an issue with absolute seeking where if a
seek is performed and the correct offset reached, the members of the multiplex
stream were not updated to reflect this.
MozReview-Commit-ID: 7lEvuXxzYkI
--HG--
extra : rebase_source : d86a7ce0fc26abd3c9a60810bd7f7f6346e7a5b0
Since we will store mCompletionPromise in the sub-class of ThenValueBase,
ThenCommand needs to reference the sub-type in order to access mCompletionPromise.
MozReview-Commit-ID: BUi7jElOhP7
--HG--
extra : rebase_source : e94c7da8488bb51e543740149925c4cb6514ad54
extra : source : 21dc7e0202dcc64a781c1d92d4d1b7988b5d37a2
This allows us to remove 2 overloads of MozPromise::Then() using variadic template.
MozReview-Commit-ID: 5LHwDhIhh8e
--HG--
extra : rebase_source : 9b84a92858736b389bd2e60aa7392bfec526ab72
extra : source : 3cdd047583693a7abf479dd75620d1c7d07da70d
PLDHashTable takes the result of the hash function and multiplies it by
kGoldenRatio to ensure that it has a good distribution of bits across
the 32-bit hash value, and then zeroes out the low bit so that it can be
used for the collision flag. This result is called hash0. From hash0
it computes two different numbers used to find entries in the table
storage: hash1 is used to find an initial position in the table to
begin searching for an entry; hash2 is then used to repeatedly offset
that position (mod the size of the table) to build a chain of positions
to search.
In a table with capacity 2^c entries, hash1 is simply the upper c bits
of hash0. This patch does not change this.
Prior to this patch, hash2 was the c bits below hash1, padded at the low
end with zeroes when c > 16. (Note that bug 927705, changeset
1a02bec165e16f370cace3da21bb2b377a0a7242, increased the maximum capacity
from 2^23 to 2^26 since 2^23 was sometimes insufficient!) This manner
of computing hash2 is problematic because it increases the risk of long
chains for very large tables, since there is less variation in the hash2
result due to the zero padding.
So this patch changes the hash2 computation by using the low bits of
hash0 instead of shifting it around, thus avoiding 0 bits in parts of
the hash2 value that are significant.
Note that this changes what hash2 is in all cases except when the table
capacity is exactly 2^16, so it does change our hashing characteristics.
For tables with capacity less than 2^16, it should be using a different
second hash, but with the same amount of random-ish data. For tables
with capacity greater than 2^16, it should be using more random-ish
data.
Note that this patch depends on the patch for bug 1353458 in order to
avoid causing test failures.
MozReview-Commit-ID: JvnxAMBY711
--HG--
extra : transplant_source : 2%D2%C2%CE%E1%92%C8%F8H%D7%15%A4%86%5B%3Ac%0B%08%3DA
PLDHashTable's entry store has two types of unoccupied entries: free
entries and removed entries. The search of a chain of entries
(determined by the hash value) in the entry store to search for an entry
can stop at free entries, but it continues across removed entries,
because removed entries are entries that may have been skipped over when
we were adding the value we're searching for to the hash, but have since
been removed. For live entries, we also maintain this distinction by
using one bit of storage for a collision flag, which notes that if the
hashtable entry is removed, its place in the entry store must become a
removed entry rather than a free entry.
When we add a new entry to the table, Add's semantics require that we
return an existing entry if there is one, and only create a new entry if
no existing entry exists. (Bug 1352198 suggests the possibility of a
faster alternative Add API where the caller guarantees that the key is
not already in the hashtable.) When we search for the existing entry,
we must thus continue the search across removed entries, even though we
record the first removed entry found to return if the search for an
existing entry fails.
The existing code adds the collision flag through the entire table
search during an Add. This patch changes that behavior so that we only
add the collision flag prior to finding the first removed entry. Adding
it after we find the first removed entry is unnecessary, since we are
not making that entry part of a path to a new entry. If it is part of a
path to an existing entry, it will already have the collision flag set.
This patch effectively puts an if (!firstRemoved) around the else branch
of the if (MOZ_UNLIKELY(EntryIsRemoved(entry))), and then refactors that
condition outwards since it is now around the contents of both the if
and else branches.
MozReview-Commit-ID: CsXnMYttHVy
--HG--
extra : transplant_source : %80%9E%83%EC%CCY%B4%B0%86%86%18%99%B6U%21o%5D%29%AD%04
Wes Kocher
Ehsan Akhgari
Mike Hommey
Sylvestre Ledru
Sebastian Hengst
Jon Coppeard
Nicholas Nethercote
Olli Pettay
Masayuki Nakano
JW Wang
Randell Jesup
Bryce Van Dyk
Daniel Holbert
Carsten "Tomcat" Book
Phil Ringnalda
Ben Kelly
L. David Baron
Ryan VanderMeulen
Bevis Tseng
Carl Corcoran