See also bug 1361495 - PR_SI_HOSTNAME is implemented in NSPR on
Windows as initializing winsock which can be janky. There don't seem
to be any users of this property, and it has tracker concerns anyhow -
so remove it.
MozReview-Commit-ID: S2AwzMUgYk
--HG--
extra : rebase_source : 552bed219913f40c002b807be3239d4666a5284b
Change mozilla::Smprintf and friends to return a UniquePtr, rather than
relying on manual memory management. (Though after this patch there are
still a handful of spots needing SmprintfFree.)
MozReview-Commit-ID: COa4nzIX5qa
--HG--
extra : rebase_source : ab4a11b4d2e758099bd0794d5c25d799a7e42680
This adds an arena allocator that can be used as a drop-in replacement for
NSPR's PLArena. Example usage for defining an 8-byte aligned allocator that
uses a 4K arena size:
mozilla::ArenaAllocator<4096,8> a;
void* memory = a.Allocate(200);
There's an antipattern where nsLiteralString is used as an unnecessary intermediary in converting from CharT* to CharT*,
e.g. CallAFunctionThatTakesACharPointer(NS_LITERAL_CSTRING("foo").get());
or
NS_NAMED_LITERAL_STRING(foo, "abc");
CallAFunctionThatTakesACharPointer(foo.get());
This patch rewrites the callsites that can be trivially changed to use char*/char16_t*.
I'd somewhat like to remove nsTLiteralString::get() altogether, but in code that's less straightforward than these examples, get() is useful enough to keep.
MozReview-Commit-ID: Kh1rUziVllo
--HG--
extra : rebase_source : c21a65694d6e1c42fd88f73632f7ac8f38d005ae
There's an antipattern where nsLiteralString is used as an unnecessary intermediary in converting from CharT* to CharT*,
e.g. CallAFunctionThatTakesACharPointer(NS_LITERAL_CSTRING("foo").get());
or
NS_NAMED_LITERAL_STRING(foo, "abc");
CallAFunctionThatTakesACharPointer(foo.get());
This patch rewrites the callsites that can be trivially changed to use char*/char16_t*.
I'd somewhat like to remove nsTLiteralString::get() altogether, but in code that's less straightforward than these examples, get() is useful enough to keep.
MozReview-Commit-ID: Kh1rUziVllo
--HG--
extra : rebase_source : c21a65694d6e1c42fd88f73632f7ac8f38d005ae
This just-so-happened to work because nobody refers to the splitter directly by name.
The added gtest doesn't actually prove that this patch fixes anything, but I figured we could use a wide string for good measure.
MozReview-Commit-ID: 1ADy4X44HO1
Handling potential nsDeque size changes means a bit of extra work.
But if the nsDeque is const, we can assume that it shouldn't get modified, so
we can provide a more optimized iterator that doesn't need to handle size
changes.
Optimizing a range-for loop in which the deque is not modified, can be done
by writing: `for (void* item : const_cast<const nsDeque&>(deque)) {...}`
MozReview-Commit-ID: AFupjoTsoH3
--HG--
extra : rebase_source : a71b09c9cb73787ce686c7c762f92ef0c208e76a
Note that iterators stay at the same index if the deque size changes
(including end-iterators staying at the end).
This means that after front operations, iterators will effectively point at
different elements! (Possibly skipping or re-visiting some.)
But this is consistent with ForEach and hand-crafted index-based for loops.
MozReview-Commit-ID: 5IvazJR68dG
--HG--
extra : rebase_source : c574fd2d2642d784482698c0fc861269200d1059
It's now possible to write:
for (void* item : deque) { ... }
MozReview-Commit-ID: FLoczCZd77y
--HG--
extra : rebase_source : 237293e94b478beb2bf352c1179d42c289dda145
There are several XPCOM tests that purport to call
NS_RegisterStaticAtoms. The tests located in the xpcom/tests/ directory
are unused, so we might as well just remove them. The gtests do get
run, but there's going to be no way to test NS_RegisterStaticAtoms once
sealing the atom table actually means forbidding new additions. So we
might as well remove the gtest too.
