The changeset has been generated automatically through:
./mach static-analysis check --output ./clang-tidy-bugprone.json --format json --fix
followed by manual adjustment when needed or when the auto-fixer bailed out.
This paves the way for Bug 2023527
Differential Revision: https://phabricator.services.mozilla.com/D287941
The changeset has been generated automatically through:
./mach static-analysis check --output ./clang-tidy-bugprone.json --format json --fix
followed by manual adjustment when needed or when the auto-fixer bailed out.
This paves the way for Bug 2023527
Differential Revision: https://phabricator.services.mozilla.com/D287941
We used to have __builtin_(...) wrapped as MOZ_ADD_OVERFLOW, SafeAdd or
used directly. Get rid of MOZ_ADD_OVERFLOW, promotes SafeAdd et cie to
mfbt and use the mfbt version everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D266685
The content of TemplateLib can be obsoleted in favor of constexpr
functions already available in mfbt/MathAlgorithms.h
- tl::Max -> std::max(x, y) or std::max({x, y, z})
- tl::Min -> std::min(x, y) or std::min({x, y, z})
- tl::FloorLog2<X>::value -> mozilla::FloorLog2(X)
- tl::CeilLog2<X>::value -> mozilla::CeilLog2(X)
- tl::RoundUpPow2<X>::value -> mozilla::RoundUpPow2(X)
- tl::BitSize<X>::value -> std::numeric_limits<X>::digits (for unsigned integral types)
- tl::MulOverflowMask<X>::value -> mozilla::MulOverflowMask(X)
the latter has been moved to mfbt/MulOverflowMask.h because it's used in
mozalloc.h and is required to have few dependencies.
also drop Windows specific code as we always build windows target with
clang-cl or mingw
Please note that the implementation of tl::CeilLog2 was incorrect for
very large numbers (typically 2**64 - 1), which impacted MulOverflowMask for those values.
This patch fixes that behavior and test it.
Differential Revision: https://phabricator.services.mozilla.com/D263523
The content of TemplateLib can be obsoleted in favor of constexpr
functions already available in mfbt/MathAlgorithms.h
- tl::Max -> std::max(x, y) or std::max({x, y, z})
- tl::Min -> std::min(x, y) or std::min({x, y, z})
- tl::FloorLog2<X>::value -> mozilla::FloorLog2(X)
- tl::CeilLog2<X>::value -> mozilla::CeilLog2(X)
- tl::RoundUpPow2<X>::value -> mozilla::RoundUpPow2(X)
- tl::BitSize<X>::value -> std::numeric_limits<X>::digits (for unsigned integral types)
- tl::MulOverflowMask<X>::value -> mozilla::MulOverflowMask(X)
the latter has been moved to mfbt/MulOverflowMask.h because it's used in
mozalloc.h and is required to have few dependencies.
also drop Windows specific code as we always build windows target with
clang-cl or mingw
Please note that the implementation of tl::CeilLog2 was incorrect for
very large numbers (typically 2**64 - 1), which impacted MulOverflowMask for those values.
This patch fixes that behavior and test it.
Differential Revision: https://phabricator.services.mozilla.com/D263523
The content of TemplateLib can be obsoleted in favor of constexpr
functions already available in mfbt/MathAlgorithms.h
- tl::Max -> std::max(x, y) or std::max({x, y, z})
- tl::Min -> std::min(x, y) or std::min({x, y, z})
- tl::FloorLog2<X>::value -> mozilla::FloorLog2(X)
- tl::CeilLog2<X>::value -> mozilla::CeilLog2(X)
- tl::RoundUpPow2<X>::value -> mozilla::RoundUpPow2(X)
- tl::BitSize<X>::value -> std::numeric_limits<X>::digits (for unsigned integral types)
- tl::MulOverflowMask<X>::value -> mozilla::MulOverflowMask(X)
the latter has been moved to mfbt/MulOverflowMask.h because it's used in
mozalloc.h and is required to have few dependencies.
also drop Windows specific code as we always build windows target with
clang-cl or mingw
Please note that the implementation of tl::CeilLog2 was incorrect for
very large numbers (typically 2**64 - 1), which impacted MulOverflowMask for those values.
This patch fixes that behavior and test it.
Differential Revision: https://phabricator.services.mozilla.com/D263523
See my comment on here for more context of my investigation:
https://bugzilla.mozilla.org/show_bug.cgi?id=1779257#c9
The saved context is invalid once the function that called `getcontext`
returns. We need to call the `getcontext` while the frame where we called it is
still on the stack. That's why this patch is moving the call to `getcontext` to
parent function by inlining the SyncPopulate content by using a macro instead.
This has to be a macro instead of a function because stack pointer address will
be invalid once the `Registers::SyncPopulate` returns. I tried to change this
method to inline but that didn't help either.
Differential Revision: https://phabricator.services.mozilla.com/D170133
In the case of FramePointerStackwalk, the caller gives a pointer to the
top-most frame to walk from. There isn't really a reason to give a
number of frames to skip, as the right frame pointer could be given in
the first place if that was really necessary. And in practice, it's
hasn't been used so far.
In the case of MozStackWalkThread, the caller presumably doesn't know
what the thread the stack is being walked for is doing, and it would be
a guesswork to pass a valid number of frames to skip. In practice, it's
also not used.
The aSkipFrames is already a footgun on MozStackWalk (and we're going to
change that in bug 1515229), we don't need to keep a footgun on these
other stack walking methods.
Differential Revision: https://phabricator.services.mozilla.com/D108563
In most situations, JSONWriter users already know string lengths (either directly, or through `nsCString` and friends), so we should keep this information through JSONWriter and not recompute it again.
This also allows using JSONWriter with sub-strings (e.g., from a bigger buffer), without having to create null-terminated strings.
Public JSONWriter functions have overloads that accept literal strings.
Differential Revision: https://phabricator.services.mozilla.com/D86192
JSONWriter currently calls new and delete indirectly through mozilla::MakeUnique to allocate a buffer. Becuase of this, the methods of this class cannot be invoked within Spidermonkey due to https://searchfox.org/mozilla-central/source/config/check_vanilla_allocations.py#6-14. Therefore, JSONWriter needs an AllocPolicy template parameter so that the allocation and deallocation routines can be changed to match the JS AllocPolicy when invoked within SpiderMonkey.
Differential Revision: https://phabricator.services.mozilla.com/D7279
Entry storage allocation now occurs on the first lookupForAdd()/put()/putNew().
This removes the need for init() and initialized(), and matches how
PLDHashTable/nsTHashtable work. It also removes the need for init() functions
in a lot of types that are built on top of mozilla::Hash{Map,Set}.
Pros:
- No need for init() calls and subsequent checks.
- No memory allocated for empty tables, which are not that uncommon.
Cons:
- An extra branch in lookup() and lookupForAdd(), but not in put()/putNew(),
because the existing checkOverloaded() can handle it.
Specifics:
- Construction now can take a length parameter.
- init() is removed. Explicit length-setting, when necessary, now occurs in the
constructors.
- initialized() is removed.
- capacity() now returns zero when the entry storage is absent.
- lookupForAdd() is no longer `const`, because it can instantiate the storage,
which requires modifications.
- lookupForAdd() can now return an invalid AddPtr in two cases:
- old: hashing failure (due to OOM in the hasher)
- new: OOM while instantiating entry storage
The existing failure handling paths for the old case work for the new case.
- clear(), finish(), and clearAndShrink() are replaced by clear(), compact(),
and reserve(). The old compactIfUnderloaded() is also removed.
- Capacity computation code is now in its own functions, bestCapacity() and
hashShift(). setTableSizeLog2() is removed.
- uint32_t is used throughout for capacities, instead of size_t, for
consistency with other similar values.
- changeTableSize() now takes a capacity instead of a deltaLog2, and it can now
handle !mTable.
Measurements:
- Total source code size is reduced by over 900 lines. Also, lots of existing
lines got shorter (i.e. two checks were reduced to one).
- Executable size barely changed, down by 2 KiB on Linux64. The extra branches
are compensated for by the lack of init() calls.
- Speed changed negligibly. The instruction count for Bench_Cpp_MozHash
increased from 2.84 billion to 2.89 billion but any execution time change was
well below noise.
serge-sans-paille