This stops the checker complaining that locks aren't held by adding further
annotations and doing some locking slightly earlier.
I've tried to adhere to the convention of passing a lock when a function
requires it, though I don't believe we have to do so to make the checker happy.
Differential Revision: https://phabricator.services.mozilla.com/D143003
For example, the SDK class android.media.MediaDrm$KeyStatus will now
be defined as MediaDrm::KeyStatus rather than just KeyStatus.
Not only does this avoid polluting the top-level namespace, but it
also avoids a bug where invalid type names were generated if the
nested class contains a method with a parameter or return of the outer
class' type.
Differential Revision: https://phabricator.services.mozilla.com/D143043
This splits the API into two, one that does a bunch of checks and calls into
the JS engine, and one for use by the CC where all preconditions are assumed to
be satisfied and can be inlined entirely.
Depends on D140865
Differential Revision: https://phabricator.services.mozilla.com/D140866
This profiler-controlling functions are used in very few places, so it's good to have them in a separate header to reduce dependencies.
On top of making GeckoProfiler.h lighter, this is actually needed for this bug, because a later patch adds MozPromise to profiler_start and others, which would have created a header loop (GeckoProfiler -> MozPromise -> Monitor -> CondVar -> GeckoProfiler) that makes the build fail.
Differential Revision: https://phabricator.services.mozilla.com/D139331
In bug 1436263, I added a cpp-virtual-final.yml linter to warn about virtual function declarations that included more than one virtual function specifier `virtual`, `final`, or `override`.
I think we should remove this linter now because:
* It's just a style check and doesn't diagnose a real bug. Including more than one virtual function specifier (`virtual`, `final`, or `override`) is harmless and unambiguous, just unnecessary extra code.
* It has caused some engineer frustration because this style check caused their changeset to be backed out of autoland. Backing out and fixing these style issues are not a good use of sheriffs' or engineers' time.
* It doesn't catch all virtual/final/override style issues because:
* It can't analyze virtual function definitions that span multiple lines.
* It doesn't check for `virtual void Foo() override` because there are over 6000 cases already, so our code will never follow this style check consistently.
Differential Revision: https://phabricator.services.mozilla.com/D139454
Make GetAppPath() defined on Mac aarch64 builds even without MOZ_SANDBOX because aarch64 builds may use it for Rosetta pre-translation.
Differential Revision: https://phabricator.services.mozilla.com/D138751
It happens to work at the moment, but it only takes some file including
RLBoxSandboxPool.h without also including nsINamed.h indirectly to break
the build. This becomes apparent when backporting RLBoxSandboxPool to
esr91.
Differential Revision: https://phabricator.services.mozilla.com/D138123
An all traces CC forces a GC to disable various cycle collector optimizations.
We never do all traces CCs normally, but they are useful for debugging leaks.
The forced GC for an all traces CC was incorrectly being given the reason
SHUTDOWN_CC, when it should be CC_FORCED. This is bad because various places in
the GC that check IsShutdownReason() will do extra cleanup during shutdown that
we don't want to do otherwise, so this patch corrects how we calculate the
reason.
I also fixed up the comment before FixGrayBits. As of bug 1749797, the
initial GC is no longer treated as suspect unless it does a full GC,
so the only time we'll actually need to force a GC during regular
operation is if the unmark gray stack overflows. I also folded in the
comment about why we force a GC for all traces CCs, and fixed a few
minor errors.
Finally, I changed mResults.mForcedGC to be true even in the case of
shutdown or an all traces CC, as I think it is more technically correct
this way, though the only impact should be on logging. An alternative
would have been to change mForceGC to be more specific to the case
of forcing a GC due to needing to fix the gray bits, but this was easier.
Differential Revision: https://phabricator.services.mozilla.com/D138026
This seems like it will be useful to help figure out what is being
created/destroyed at inappropriate times, and identify potential
problems faster.
Differential Revision: https://phabricator.services.mozilla.com/D136944