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
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
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
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
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
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
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
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
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
Jeff Walden
Jason Orendorff
Cosmin Sabou
Chris Peterson
Sylvestre Ledru
Alfredo.Yang
Gerald Squelart
Lee Salzman
Mike Hommey
Luke Wagner
Matt Woodrow
Wes Kocher
Chris Manchester
Phil Ringnalda
Botond Ballo
Petr Sumbera
Henri Sivonen
Bas Schouten
Carsten "Tomcat" Book
Olli Pettay