The generic fallback MOZ_FALLTHROUGH definition is insufficient for GCC 7 and
above, resulting in --enable-warnings-as-errors builds failing.
The check for clang support is changed to use the __has_cpp_attribute macro,
which is more robust than checking the __cplusplus version.
Also, MOZ_FALLTHROUGH is now only defined in C++ code, since GCC errors out if
it encounters a scoped attribute being used with __has_cpp_attribute in C code.
No C code uses MOZ_FALLTHROUGH or derivatives at the moment.
MozReview-Commit-ID: 4nKFBRD5jSF
--HG--
extra : rebase_source : 0c37ae39c806ca24a3271d3ec19531dd16e05daf
We have a minimum requirement of VS 2015 for Windows builds, which supports
the z length modifier for format specifiers. So we don't need SizePrintfMacros.h
any more, and can just use %zu and friends directly everywhere.
MozReview-Commit-ID: 6s78RvPFMzv
--HG--
extra : rebase_source : 009ea39eb4dac1c927aa03e4f97d8ab673de8a0e
Changes made:
* Add IPC::ParamTraits as a friend to mozilla::Variant in Variant.h.
This is required so that `tag` can be accessed in the
IPC::ParamTraits specialization.
* Add a IPC::ParamTraits specialization to IPCMessageUtils.h.
MozReview-Commit-ID: B3pGrZE1z0O
--HG--
extra : rebase_source : cb73873b87401846f79e124249c7ce00dff2de77
These macros can be used in cases where the `mozilla` namespace might
not refer to the toplevel `mozilla` namespace that was intended. To
ensure that the macros always refer to the `mozilla` namespace in the
global namespace, use the appropriate qualification.
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
