If class A is derived from class B, then an instance of class A can be
converted to B via a static cast, so a slower QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6861
--HG--
extra : moz-landing-system : lando
_CrtSetReportXxxx stuff is dead decause we do not use debug CRT even in debug
builds for a long time. So I removed it to fix -Wunused-function.
--HG--
extra : source : ba00278fc1deee805e7ed13d0dc0658dee13465c
extra : intermediate-source : 5ffdd1f9f2562f9915f3c8805218fa33a908be20
This patch causes Firefox processes created via LaunchChild to start via the
launcher process.
While this extra hop through the launcher process takes longer than if we were
to simply make LaunchChild use the same code as the launcher process itself,
I do not want to simply export LauncherProcessMain from firefox.exe, as that
would be too easy to hook into and mess with.
Another option would be to host a second copy of the launcher code inside
xul.dll, but that's less than ideal.
Anyway, until we get that figured out, I don't think it's too big a deal to
have this extra hop in place. I don't think anybody has been clamoring for
faster restarts from the updater or the profile manager.
Depends on D4496
Differential Revision: https://phabricator.services.mozilla.com/D4497
--HG--
extra : moz-landing-system : lando
Add StartOpenBSDSandbox method calling pledge() syscall,
and use it where we're sandboxing processes.
The pledge subsets are coming from two new prefs:
- security.sandbox.pledge.content for the content process
- security.sandbox.pledge.main for the main process
--HG--
extra : rebase_source : 60da70e2d335755fda6126a6b7de7aad41eebb7e
Correctness improvements:
* UTF errors are handled safely per spec instead of dangerously truncating
strings.
* There are fewer converter implementations.
Performance improvements:
* The old code did exact buffer length math, which meant doing UTF math twice
on each input string (once for length calculation and another time for
conversion). Exact length math is more complicated when handling errors
properly, which the old code didn't do. The new code does UTF math on the
string content only once (when converting) but risks allocating more than
once. There are heuristics in place to lower the probability of
reallocation in cases where the double math avoidance isn't enough of a
saving to absorb an allocation and memcpy.
* Previously, in UTF-16 <-> UTF-8 conversions, an ASCII prefix was optimized
but a single non-ASCII code point pessimized the rest of the string. The
new code tries to get back on the fast ASCII path.
* UTF-16 to Latin1 conversion guarantees less about handling of out-of-range
input to eliminate an operation from the inner loop on x86/x86_64.
* When assigning to a pre-existing string, the new code tries to reuse the
old buffer instead of first releasing the old buffer and then allocating a
new one.
* When reallocating from the new code, the memcpy covers only the data that
is part of the logical length of the old string instead of memcpying the
whole capacity. (For old callers old excess memcpy behavior is preserved
due to bogus callers. See bug 1472113.)
* UTF-8 strings in XPConnect that are in the Latin1 range are passed to
SpiderMonkey as Latin1.
New features:
* Conversion between UTF-8 and Latin1 is added in order to enable faster
future interop between Rust code (or otherwise UTF-8-using code) and text
node and SpiderMonkey code that uses Latin1.
MozReview-Commit-ID: JaJuExfILM9
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant C++ functions are updated to take a typed enum. JavaScript
calls are unaffected but they will throw if the string argument does not
correspond to one of the known entries in the C++ enum. The existing whitelists
and blacklists of annotations are also generated from the YAML file and all
duplicate code related to them has been consolidated. Once written out to the
.extra file the annotations are converted in string form and are no different
than the existing ones.
All existing annotations have been included in the list (and some obsolete ones
have been removed) and all call sites have been updated including tests where
appropriate.
--HG--
extra : source : 4f6c43f2830701ec5552e08e3f1b06fe6d045860
widget/windows/WinUtils.h is getting unwieldy and contains a combination of
both header-only and non-header-only code. I thought I'd take the opportunity
with this patch to create a new file for self-contained, header-only utility
functions, with the hope that we can eventually migrate some stuff out of
WinUtils into WinHeaderOnlyUtils in the future.
--HG--
extra : rebase_source : 6c874f78fc7113d1f7011fcd57ad9d024edb6761
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
This is to accommodate non-networking fd usage (IPC transports, various
databases, .xpi files, etc.), so it's separate from Necko's existing
manipulation of the fd limit, which is tied into Necko's internal limits
on how many sockets it will try to poll at once.
Note that resource limits are inherited by child processes, so this needs
to be done only in the parent.
This patch also removes similar code used on Solaris and Mac OS X. The
Mac case (bug 1036682) refers to fd use by graphics textures, which
shouldn't be consuming fds anymore (even transiently) as of bug 1161166.
MozReview-Commit-ID: 2uodrkW5sUn
--HG--
extra : rebase_source : 5306f4995000459b89bed048ecafba3c262bbbdf