Making this constructor non-explicit will permit automatic conversions from
'nullptr' into RefPtr types, which I think are not dangerous.
The one spot that this affects is in 'UserDataType nsBaseHashtable::Get(KeyType)',
which does a 'return 0;' into the UserDataType, which could be a bool, an int, a
RefPtr or other. I'm changing that into a C++11 "value initialization", which
falls back to "zero initialization" for PODs: 'return UserDataType{};'.
Also fixed the comment to clarify not-found return values, as Get(KeyType) was
not only used for pointers anyway.
MozReview-Commit-ID: F41VlvTNOZU
--HG--
extra : rebase_source : 71d5dacac75ca188e5c55d45f48a5fca76d953c6
Added constructor and operator= from a nullptr, bypassing the incoming pointer
check.
Note that the constructor is 'explicit', because one particular use in
nsBaseHashtable is doing a 'return 0' into a templated type that is a RefPtr in
many cases. Making this new constructor explicit removes it from consideration
in this case.
As it's not strictly necessary to have it MOZ_IMPLICIT (but could still be
nice), I will tackle that in the patch after next.
Also changed all zeroes into nullptr when relevant in RefPtr.h (other system-
wide affected files will be updated in following patch.)
MozReview-Commit-ID: Ds4CEv9hZWI
--HG--
extra : rebase_source : f4ec156b13ea3bdcf32b1a33d76ff9771ad6d1dc
Since |T*| converts into |const T*|, if we want to rewrite code such as:
void DoSomething(const T*, size_t);
void DoSomethingElse(T* x, size_t len)
{
...
DoSomething(x, len);
}
to use ranges:
void DoSomething(Range<const T>);
void DoSomethingElse(Range<T> x)
{
...
DoSomething(x);
}
we need to ensure this conversion works. gsl::span<T> already provides
something like this as well.
We needed this polyfill for <initializer_list> when some of our C++
standard libraries did not support said header. They all do now, so the
polyfill is redundant.
With this change, we could share this EnumTypeTraits between files easily.
MozReview-Commit-ID: 9Q2augati7l
--HG--
extra : rebase_source : b7d9fc95d9d7722ba3eb99ec9798a64ebdbeb484
Check if the buffers iterator was never consumed. This is a regression
introduced when converting ipc to use BufferList in bug 1262671.
MozReview-Commit-ID: LWAoVlI5CKJ
--HG--
extra : rebase_source : c4f16f4f90f56153c10cf1d9113c4c55748595f0
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
In JS StructuredClone BufferList<SystemAllocPolicy> is typedef'd to
JSStructuredCloneData and use everywhere in gecko that stores structured
clone data.
This patch changed some raw pointers to UniquePtr<JSStructuredCloneData>
and some to stack allocated JSStructuredCloneData for better life time
management. Some parameters or methods are deleted because of changing
to the new data structure.
MessagePortMessage now has the exactly same structure with
ClonedMessageData. Maybe in the future they can be consolidated.
MozReview-Commit-ID: 1IY9p5eKLgv
These methods allow us to move some buffers out of a pickle with minimum
copying. It's useful when the IPC deserialized type uses BufferList to
store data and we want to take the buffers from IPC directly.
Borrowing is not suitable to use for IPC to hand out data because we
often want to store the data somewhere for processing after IPC has
released the underlying buffers.
MozReview-Commit-ID: F1K2ZMkACqq
