MozReview-Commit-ID: 6lxZWDPc6ZQ
I need to be able to distinguish between builds of Windows 10. Unfortunately the
stuff that I am working with cannot be sorted out via feature detection.
--HG--
extra : rebase_source : 6da46f31815b2938d9a7a984473ed01c35b8a59d
If MOZ_CRASH_UNSAFE_PRINTF is only given a format string, it means
either arguments are missing, or MOZ_CRASH should be used instead.
Hint at that with a static_assert.
--HG--
extra : rebase_source : 355c37deb8b007e61939a4c657e411d110e7bbe7
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
I'm not sure how I tested MOZ_FOR_EACH in bug 1368932, but it turns out
it doesn't work with an empty list, despite
MOZ_PASTE_PREFIX_AND_ARG_COUNT now supporting 0 arguments.
Macros can be tricky, and it ends up being easier to make things work
cross-compiler with a separate macro that does the counting, and
(re)building MOZ_PASTE_PREFIX_AND_ARG_COUNT on top of that. Then
MOZ_FOR_EACH ends up working as expected with an empty list.
So this adds a MOZ_ARG_COUNT macro that counts the number of variadic
arguments it's given, and derives MOZ_PASTE_PREFIX_AND_ARG_COUNT from
it.
And this adds a testcase validating that MOZ_FOR_EACH works properly
with an empty list as a result.
--HG--
extra : rebase_source : 309371d87bd1561fbd2153f44fc1256185045d23
Without the Move(), a temporary copy is created and passed as rvalue.
MozReview-Commit-ID: B3MXz6yzO39
--HG--
extra : rebase_source : 897493da0dfac983449da3853fe60bd6ac93117b
At the same time, remove the MOZ_STATIC_ASSERT_VALID_ARG_COUNT, which
doesn't actually work for more than 50 arguments(*), and which is now not
useful to detect 0 arguments.
(*) the build fails, but not directly thanks to the static_assert it
expands to.
--HG--
extra : rebase_source : 8f0fe7b352c89b5a3ec87f42ef5464c370c362ef
MinGW applies the gnu_printf format attribute, which expects
non-Windows format specifiers. These macros were not designed
to handle MinGW.
MozReview-Commit-ID: HuJrK43Bg1A
--HG--
extra : rebase_source : 6ccc1b2f4ab0e71584f442e86d94322e2c6382fb
Every platform where we use GCC has <atomic>, so there's no need to use
GCC-specific __sync* intrinsics anymore. The <atomic> header may
generate better code for several operations, as well.
This annotates vsprintf-like functions with MOZ_FORMAT_PRINTF. This may
provide some minimal checking of such calls (the GCC docs say that it
checks for the string for "consistency"); but in any case shouldn't
hurt.
MozReview-Commit-ID: HgnAK1LiorE
--HG--
extra : rebase_source : 9c8d715d6560f89078c26ba3934e52a2b5778b6a
On 64-bit Android, the inttypes.h macros for [u]int_fastN_t types (e.g.
int_fast16_t) use "d", "u", etc. as the format specifier, but the types
themselves are defined as `long`, `unsigned long`, etc. This patch
redefines the macros as `PRId64`, `PRIu64`, etc. to provide correct
behavior.
Bug 1348419 enabled thread-local storage for Mac, but only Xcode 8+
supports that feature, which busted building with Xcode 7-. This change
fixes that bustage by ensuring a Mac compiler supports the feature
before using it.
Bug 1348419 enabled thread-local storage for Mac, but only Xcode 8+
supports that feature, which busted building with Xcode 7-. This change
fixes that bustage by ensuring a Mac compiler supports the feature
before using it.
