The macro simultaneously declares an enumeration and a count of its
enumerators.
A few variants of the macro are also provided to handle things like
enum classes, underlying types, and enumerations declared at class
scope.
MozReview-Commit-ID: 3z6yHnfXbLj
--HG--
extra : rebase_source : 92c333693e4bbf85b89cd3d7ac5b31f4b5434367
The -fsanitize=integer analysis from UBSan can be helpful to detect signed and unsigned integer overflows in the codebase. Unfortunately, those occur very frequently, making it impossible to test anything with it without the use of a huge blacklist. This patch includes a blacklist that is broad enough to silence everything that would drain performance too much. But even with this blacklist, neither tests nor fuzzing is "clean". We can however in the future combine this with static analysis to limit ourselves to interesting places to look at, or improve the dynamic analysis to omit typical benign overflows.
It also adds another attribute that can be used on functions. It is not used right now because it was initially easier to add things to the compile-time blacklist to get started.
Finally, it includes a runtime suppression list and patches various parts in the test harnesses to support that. It is currently empty and it should not be used on frequent overflows because it is expensive. However, it has the advantage that it can be used to differentiate between signed and unsigned overflows while the compile-time blacklist cannot do that. So it can be used to e.g. silence unsigned integer overflows on a file or function while still reporting signed issues. We can also use this suppression list for any other UBSan related suppressions, should we ever want to use other features from that sanitizer.
MozReview-Commit-ID: C5ofhfJdpCS
--HG--
extra : rebase_source : 952043a441b41b2f58ec4abc51ac15fa71fc142f
The -fsanitize=integer analysis from UBSan can be helpful to detect signed and unsigned integer overflows in the codebase. Unfortunately, those occur very frequently, making it impossible to test anything with it without the use of a huge blacklist. This patch includes a blacklist that is broad enough to silence everything that would drain performance too much. But even with this blacklist, neither tests nor fuzzing is "clean". We can however in the future combine this with static analysis to limit ourselves to interesting places to look at, or improve the dynamic analysis to omit typical benign overflows.
It also adds another attribute that can be used on functions. It is not used right now because it was initially easier to add things to the compile-time blacklist to get started.
Finally, it includes a runtime suppression list and patches various parts in the test harnesses to support that. It is currently empty and it should not be used on frequent overflows because it is expensive. However, it has the advantage that it can be used to differentiate between signed and unsigned overflows while the compile-time blacklist cannot do that. So it can be used to e.g. silence unsigned integer overflows on a file or function while still reporting signed issues. We can also use this suppression list for any other UBSan related suppressions, should we ever want to use other features from that sanitizer.
MozReview-Commit-ID: C5ofhfJdpCS
--HG--
extra : rebase_source : 64aa804965d24bb90b103c00c692a2ac6859e408
mfbt/tests/TestDoublyLinkedList.cpp:138:24 [-Wunused-member-function] unused member function 'GetPrev'
MozReview-Commit-ID: HQuTw0vXRKV
--HG--
extra : source : 0db3bd8a40d67a81b2f224dc9e63012cb832d0b9
extra : intermediate-source : 948c43ff15b4ca1a3db335544494562ec28e67cc
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.
Remove the definition of sig_safe_t, which is only used by PseudoStack,
and replace the uses with mozilla::Atomic<uint32_t>.
MozReview-Commit-ID: GcPd9R94Vci
--HG--
extra : rebase_source : dcc05a219d59ffdc0486ef2e7118d888c6a93fda
I can't speak for whether the MOZ_SPAN_GCC_CONSTEXPR on operator> is necessary, but I'm going on the assumption that any callers of it must also be in the same bucket of constexpr-ness.
