This class implements a shared memory key-value store that fits into a single
memory mapped segment. All of the runtime data for its instances are stored in
the shared memory region, which means that memory overhead for each instance
in each process is only a few bytes.
Importantly, the key and value strings returned by this class are also
pointers into the shared memory region, which means that once an instance is
created, its memory cannot be unmapped until process shutdown.
For the uses I intend to put it to, this is a reasonable constraint. If we
need to use it for shorter-lived maps in the future, we can add an option to
return non-literal dependent strings that will be copied if they need to be
kept alive long term.
MozReview-Commit-ID: 5BwAaDsb7HS
--HG--
extra : rebase_source : b472fe628018f88a2c4d6b3de4b7143aeca55e14
extra : absorb_source : 5cdeb568cfd2b4a5a767191402e699e61e653b3b
Scalar property names (e.g. IntProperty) are already escaped correctly.
This patch escapes the collection property names (e.g. StartObjectProperty)
as well (and adds test coverage for it).
MozReview-Commit-ID: 68kkjPb2ZN7
--HG--
extra : rebase_source : b42939ccebb71fc73914ff595803b2d6c7df2715
This adds 'CorruptionCanaryForStatics', which as the name implies is suitable
for use in objects that are statically declared. It has a trivial destructor
which allows us to avoid the need for static constructors.
--HG--
extra : amend_source : 27f8eff9ead21fde9f5f5d17f16c322d2c995a27
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
... to allow a user to remove() an entry, update the values and
re-insert() it into a tree.
MozReview-Commit-ID: GrSY90Q3ugt
--HG--
extra : rebase_source : 9d8876064f9e3d5b9e4249936a4c999b74fcc9ad
When we use RefPtr with nsISupports sub-classes, it's usually because the type
cannot be unambiguously cast to nsISupports. We already have a ToSupports
generic function to resolve ambiguity in these cases, so we may as well use
it here.
MozReview-Commit-ID: FaHhPKAPn6j
--HG--
extra : rebase_source : dd8f3707bdebedfe559aed0caf2c3b0c49163735
extra : histedit_source : 9805787a169329b9c739dfa456cfe6a61a22b7d7
We out-of-line the relevant functions because assertions can generate
quite a bit of code, and we'd rather let the compiler determine if these
functions should be inlined now.
For some reason, GNU as is not happy with the assembly generated after
bug 1238661 anymore on Debian armel.
OTOH, as mentioned in bug 1238661 comment 4, we actually don't need this
workaround anymore, so let's just kill it.
--HG--
extra : rebase_source : 6fd06832136d4f840c65f74b63f1c1bec48d525d
We out-of-line the relevant functions because assertions can generate
quite a bit of code, and we'd rather let the compiler determine if these
functions should be inlined now.
NonDereferenceable denotes the intent that a pointer will (most likely) not be
dereferenced, but its numeric value may be used for e.g. logging purposes.
Dereferencing operations are explicitly disabled to avoid unintentional misuses.
Casting is still possible between related types (same as with raw pointers),
but pointers stay safely stored inside NonDereferenceable objects. These casts
do not trigger `clang++ -fsanitize=vptr` errors.
MozReview-Commit-ID: 5885pB7hSFR
--HG--
extra : rebase_source : 3c4011da64d84f1b19991742b76bafbffa90d590
There are three things we want to be true:
a) If the child sends a large value and the parent can't allocate enough space
for it we use an infallible allocation so the parent dies with an OOM.
b) If a fuzzer generates (huge-length, small-data) we don't try to allocate
huge-length bytes; knowing that the read will fail.
c) No fuzzer-specific branches in the core IPC serialization code.
Finally, this makes (huge-length, small-data) consistent with other cases where
the data is potentially truncated: ReadParam returns false.
MozReview-Commit-ID: 6nDKrw5z4pt
--HG--
extra : rebase_source : 58372d29139e9545a6ed2852c7243affeab6fdb7
Otherwise, one can do thinkos like:
MakeScopeExit(...);
and the scope exiting function will execute much earlier than the
intended:
auto guard = MakeScopeExit(...);
This is a `constexpr` alternative to HashString(const char16_t*). We can't make
HashString(const char16_t*) itself `constexpr` because HashUntilZero(const T*)
isn't in a form that older compilers (like GCC 4.9) allow to be made
`constexpr`. (The trick to satisfying those compilers is to use recursion
instead of iteration, to get the function into a single `return` statement.)
This requires making a bunch of other functions `constexpr` as well. It also
requires adding MOZ_{PUSH,POP}_DISABLE_INTEGRAL_CONSTANT_OVERFLOW_WARNING
macros to avoid some MSVC weirdness.
The introduction of RotateLeft5() partly undoes one of the patches from bug
1443342, but that's unavoidable.
This change will help with static allocation of static atoms (bug 1411469).
MozReview-Commit-ID: 7r3PnrQXb29
VS 2017 15.6 (March 2018) doesn't seem to understand
`*DeclVal<SharedFontList*>()` anymore.
To work around this issue, the pointed-to type is now extracted in a separate
struct, for which we provide a specialization for raw pointers, so we don't
encounter the shaky `*DeclVal<T*>()` statement anymore.
MozReview-Commit-ID: FuslManbfdB
--HG--
extra : rebase_source : be3813aa9a028e6891cb3de1fc4faae5bde0348e
mozWritePoison secretly depended on the passed-in pointer being aligned
as though it were a pointer to uintptr_t, as it used bare stores to
C-casted pointers to accomplish poisoning. But this is an unnecessary
limitation: we can use memcpy and rely on the compiler to appropriately
inline the store to an unaligned store instruction if necessary.
The documentation for mozWritePoison says that only an even number of
sizeof(uintptr_t) bytes are overwritten; any trailing bytes are not
touched. This documentation doesn't correspond to how the function
actually works. The function as written will happily overwrite trailing
bytes and any bytes not contained in the object, if the passed-in size
isn't divisible by sizeof(uintptr_t). Let's fix that.
Given that we have a SegmentedVector of nsCOMPtrs, it's probably worth
avoiding copying it.
MozReview-Commit-ID: GHyfVLrdnlQ
--HG--
extra : rebase_source : 75df805d8b2df32b76ee77b95ced625f20331744
This is drop-in replacements of std::ifstream and std::ofstream, but supports
widechar filenames on Windows. This is just an alias of std::ofstream on other
platforms.
MozReview-Commit-ID: FHNatG5595k
--HG--
extra : rebase_source : 0805153dd13907a6c3b6971bfc0b499a31416b9a
extra : intermediate-source : 3113df1e69bf7444105953df8610b8bbf5d4d41e
extra : source : 750263b126963d2634a89de0a2aac63efa4b49e6
In Bug 1393538 I renamed MOZ_STATIC_ASSERT_UNUSED_ATTRIBUTE to MOZ_UNUSED_ATTRIBUTE,
moved it out of it's #define depth, and used it in toolkit. I also orphaned a
comment.
This was wrong. MOZ_UNUSED_ATTRIBUTE was basically identical to MOZ_MAYBE_UNUSED
which exists in Attributes.h (because it is an attribute, not an assertion.)
Undo that wrong thing: restore MOZ_STATIC_ASSERT_UNUSED_ATTRIBUTE to the correct
place, have toolkit use the correct macro, and remove MOZ_UNUSED_ATTRIBUTE.
MozReview-Commit-ID: 5BWWsXgbm9i
--HG--
extra : rebase_source : d07156068c877bf57d400bc6a71e115b7f1aef31
Currently only |value_type| is implemented.
MozReview-Commit-ID: 1mejzvkuako
--HG--
extra : rebase_source : 69e08073adbb9a866db26e515702a0659ece0a70
extra : intermediate-source : 3696381ddfdc19ab2f901ca4247e1cb4efb27731
extra : source : 35d760da1d73dd51614f434c26e5ce80ff690829
clang-cl fails to build without this change due to ambiguous call.
MozReview-Commit-ID: 22x5PCsG221
--HG--
extra : rebase_source : 93d2d50abc126286ad78c1f3700fe358c507a826
extra : intermediate-source : a9c64eaa326a2c694456d2e8907074f75b66c645
extra : source : c0b55d2093f59a8dabf2640106befa0dae516906
Apply 63a7f34fee
to our copy of lz4.h to allow to flag the lz4 symbols as not exported.
--HG--
extra : rebase_source : d9aafb04a56c0ae3620e0c873f77d124386a41c4
The library was added in bug 1160285 for webapprt, and webapprt was
removed in bug 1238079.
--HG--
extra : rebase_source : 8e47523263eb53707b0d916cc550418f1bc646ef
We out-of-line the relevant functions because release assertions can
generate quite a bit of code, and we'd rather let the compiler determine
if these functions should be inlined now.
MakeNotNull is similar to UniquePtr, in that it combines the infallible
allocation and construction of an object on the heap and wraps the (raw or
smart) pointer into a NotNull.
It skips the unnecessary null check from WrapNotNull, and removes the usual
naked 'new' used in many WrapNotNull calls.
MozReview-Commit-ID: UwCrhDnkUg
--HG--
extra : rebase_source : 5a027165fc17ed748783c7ffda03eb421865ad6e
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
Delete Span's implicit constructors for char* and char16_t* pointers to avoid accidental construction in cases where a pointer does not point to a zero-terminated string. Use the MakeStringSpan() function instead.
I deleted both the const and non-const char* and char16_t* constructors, in the name of cross-compiler consistency. If we only delete the const char* and char16_t* constructors, for some reason, MSVC complains that `Span<char> s(charArray)` uses a deleted constructor while clang nor gcc permit it. I don't know if this is a compiler bug in MSVC or clang and gcc.
Also, do not permit MakeSpan() for string literals (const char and char16_t arrays) because the Span length would include the zero terminator, which may surprise callers. Use MakeStringSpan() to create a Span whose length that excludes the string literal's zero terminator or use the MakeSpan() overload that accepts a pointer and length and specify the string literal's full length.
The following Span usages are prevented:
Span<const char> span("literal"); // error
Span<char> span(charArray); // error
Span<const char> span;
span = "literal"; // error
span = charArray; // error
MakeSpan("literal"); // error
The following Span usages are still permitted:
assert(MakeStringSpan("literal") == 8); // OK: span length is calculated with strlen() and excludes the zero terminator
MakeStringSpan(charArray); // OK: span length is calculated with strlen() and excludes the zero terminator
MakeSpan(charArray); // OK: span length is the char array size including any zero terminator
MozReview-Commit-ID: Et71CpjsiyI
--HG--
extra : rebase_source : f6f8bdb28726f0f2368fdfdd039fb1d7dcf2914e
extra : source : 0547d8924ffc7713d6cf32cc06eeeaf00e0d69a3
ThreadLocalKeyStorage uses Thread Local APIs that are declared in
processthreadsapi.h (although it's more common to just include
windows.h). If a caller wants to use this class, it is their
responsibility to include an appropriate header before including
ThreadLocal.h
MozReview-Commit-ID: GO5dHKVWpZO
--HG--
extra : rebase_source : ff8d6cda1eed7bd9d54745c869b4e47a895b605a
There are use cases for wanting a specific TLS implementation
independently of whether __thread or thread_local are supported.
This is one step in that direction, making the
pthread_{get,set}specific-based implementation available independently.
We still keep everything under the mozilla::detail namespace because
it's still better if people don't try to use mozilla::ThreadLocal
directly.
--HG--
extra : rebase_source : 095b95a577b85efaaf2f3c0b7c3ac968ff711738
Mozjemalloc uses its own doubly linked list, which, being inherited from
C code, doesn't do much type checking, and, in practice, is rather
similar to DoublyLinkedList, so use the latter instead.
--HG--
extra : rebase_source : 9eb7334b6dde05f9af0eaea4184e532c69d0264e
While the flexibility of the current trait is nice, it's actually not
used to its fullest anywhere, and is boilerplate-y. While it is useful
to be able to put the links anywhere, there's not much usefulness from
being able to split mNext and mPrev.
So instead of a trait that allows to get/set mNext and mPrev
independently, we just use a trait that tells how to get a reference to
a DoublyLinkedListElement from a list element itself.
--HG--
extra : rebase_source : 674277bac4fc979f2e483a77b5ef1495baccc7fe
Mozjemalloc uses its own doubly linked list, which, being inherited from
C code, doesn't do much type checking, and, in practice, is rather
similar to DoublyLinkedList, so use the latter instead.
--HG--
extra : rebase_source : 1d40653b8117e28d8633134f379540c3c517a306
While the flexibility of the current trait is nice, it's actually not
used to its fullest anywhere, and is boilerplate-y. While it is useful
to be able to put the links anywhere, there's not much usefulness from
being able to split mNext and mPrev.
So instead of a trait that allows to get/set mNext and mPrev
independently, we just use a trait that tells how to get a reference to
a DoublyLinkedListElement from a list element itself.
--HG--
extra : rebase_source : f84c5799c305a4a3b7dc5deb727a05d4d537bb15
Mozjemalloc uses its own doubly linked list, which, being inherited from
C code, doesn't do much type checking, and, in practice, is rather
similar to DoublyLinkedList, so use the latter instead.
--HG--
extra : rebase_source : 7f2c03d6ba5c1da5d8badb0de710b7900e9d00c1
While the flexibility of the current trait is nice, it's actually not
used to its fullest anywhere, and is boilerplate-y. While it is useful
to be able to put the links anywhere, there's not much usefulness from
being able to split mNext and mPrev.
So instead of a trait that allows to get/set mNext and mPrev
independently, we just use a trait that tells how to get a reference to
a DoublyLinkedListElement from a list element itself.
--HG--
extra : rebase_source : b7d502754a764670e291acdd56726948db935497
Also adds a mozilla/ResultExtensions.h header to define the appropriate
conversion functions for nsresult and PRResult. This is in a separate header
since those types are not available in Spidermonkey, and this is the pattern
other *Extensions.h headers follow.
Also removes equivalent NS_TRY macros and WrapNSResult inlines that served the
same purpose in existing code, and are no longer necessary.
MozReview-Commit-ID: A85PCAeyWhx
--HG--
extra : rebase_source : a5988ff770888f901dd0798e7717bcf6254460cd
This allows MOZ_TRY and MOZ_TRY_VAR to be transparently used in XPCOM methods
when compatible Result types are used.
Also removes a compatibility macro in SimpleChannel.cpp, and an identical
specialization in AddonManagerStartup, which are no longer necessary after
this change.
MozReview-Commit-ID: 94iNrPDJEnN
--HG--
extra : rebase_source : 24ad4a54cbd170eb04ded21794530e56b1dfbd82
When used as an error value, nsresult should never be NS_OK, which means that
we should be able to safely pack simple nsresult Result values into a single
word.
MozReview-Commit-ID: GJvnyTPjynk
--HG--
extra : rebase_source : ab5a64b545dfbfe9bbef167f8b63ecbf00b16e07
This makes sure that:
* We don't define `MOZ_GLUE_IN_PROGRAM` so that everything in mozglue gets
defined.
* `MFBT_API`'s symbol export rules match `JS_PUBLIC_API` and `EXPORT_JS_API`.
* We add mozglue to SpiderMonkey's `USE_LIBS` when jemalloc is disabled.
/home/worker/workspace/build/src/mozglue/build/WindowsDllBlocklist.cpp:816:1: error: 'noreturn' function does return [-Werror]
MozReview-Commit-ID: SYgPDW0sMV
--HG--
extra : rebase_source : 27b1dda404b3fc5fab95dd524677387bad921751
nsQueryReferent is defined as an nsCOMPtr_helper, which implies that
calling its operator() method requires a virtual call. While
nsQueryReferent is marked `final`, compiler inlining decisions make it
impossible to de-virtualize the call to operator(). However, we have
many other classes returned by do_* functions that nsCOMPtr handles
directly, requiring no extra virtual calls, and we can give
nsQueryReferent the same treatment.
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