This patch makes the error codes in nsError.h be generated by a python script.
This gives us the opportunity to add rust code generation in parallel with the
C++ code generation, which will happen in part 2.
This patch also reworks the name calculation in ErrorNames.cpp to use generated
code by the python script.
MozReview-Commit-ID: 5wxbdZwxe7q
This patch makes the error codes in nsError.h be generated by a python script.
This gives us the opportunity to add rust code generation in parallel with the
C++ code generation, which will happen in part 2.
This patch also reworks the name calculation in ErrorNames.cpp to use generated
code by the python script.
MozReview-Commit-ID: 5wxbdZwxe7q
This uses std::atomic rather than mozilla::Atomic since mozilla::Atomic
does not support using different memory synchronization for different
atomic operations on the same variable.
The added comments could use careful review since, while they reflect my
understanding of the issue, I don't consider myself an expert on the
topic.
MozReview-Commit-ID: 7xByCXt17Dr
--HG--
extra : transplant_source : %8DM%88%E8%B7%B4%D8a%D6%F5%3F%9B%DC%09X%F3%7C%98%DE%21
This uses std::atomic rather than mozilla::Atomic since mozilla::Atomic
does not support using different memory synchronization for different
atomic operations on the same variable.
The added comments could use careful review since, while they reflect my
understanding of the issue, I don't consider myself an expert on the
topic.
MozReview-Commit-ID: 7xByCXt17Dr
--HG--
extra : transplant_source : 8%8Ci%CC%EA%0F%CF%C7%3E%F1%93%F5%C9%ED9%84%F9%3Evx
For testing purposes it will be useful to be able to trigger crashes in Rust
code. Being able to trigger a panic seems like a good place to start. This
will make it easier to validate improvements in crash reporting.
MozReview-Commit-ID: Bh5rBieLLWW
--HG--
rename : toolkit/crashreporter/test/unit/test_crash_moz_crash.js => toolkit/crashreporter/test/unit/test_crash_rust_panic.js
extra : rebase_source : ba9f626ca2d2852f966e93401b8f8f7543615310
extra : source : 8c9117de1e7f40af42b7cbce25bc3780c032fe45
For testing purposes it will be useful to be able to trigger crashes in Rust
code. Being able to trigger a panic seems like a good place to start. This
will make it easier to validate improvements in crash reporting.
MozReview-Commit-ID: Bh5rBieLLWW
--HG--
rename : toolkit/crashreporter/test/unit/test_crash_moz_crash.js => toolkit/crashreporter/test/unit/test_crash_rust_panic.js
extra : rebase_source : 0ac96469629a7a933fcf3bf6720c448db45543eb
extra : source : 8c9117de1e7f40af42b7cbce25bc3780c032fe45
It's a very general mechanism for replacing the implementation of
printf_stderr().
It's primarily used by the profiler, sparingly, and not in an important way.
Worse, it prevents us from using MOZ_LOG in the profiler, which is something I
want. Because if any code that locks gPSMutex also calls MOZ_LOG, that then
calls printf_stderr(), which calls profiler_log(), which locks gPSMutex, which
deadlocks.
The only other use of set_stderr_callback() is for the ultra-hacky,
for-local-use-only copy_stderr_to_file() function, which was added for B2G
debugging and is no longer necessary.
This patch removes set_stderr_callback() altogether.
--HG--
extra : rebase_source : d31ecb482fe5899f62dc56a38e87d91f9271bab0
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
It's fairly straightforward, and measures the important parts of:
- Sampler, PseudoStack, ProfileBuffer, ThreadInfo.
- LUL, PriMap, SecMap
Coverage isn't perfect, but it gets the major things I found via DMD on Linux.
Example output in about:memory:
├──151.21 MB (49.73%) -- profiler
│ ├──141.49 MB (46.53%) ── lul
│ └────9.72 MB (03.20%) ── sampler
--HG--
extra : rebase_source : 67d2ada42aead43f68f5100a08204a1d1f1cfceb
We can make some assumptions now that the Input method is only called once and never again while a decode is pending.
MozReview-Commit-ID: EmzKEcwNY2J
--HG--
extra : rebase_source : 42ae59878962b425970a60abe25d98c023ef4fdf
This way we can't end up with a situation in which an ancestor doesn't care about skippability but a descendant does and doesn't get it, because the ancestor just claimed no skippability was needed.
With frame pointer omission disabled we should always have usable stacks on Windows. This allows us to remove the MOZ_STACKWALKING define as it will always be enabled.
MozReview-Commit-ID: 54xs3Hf1r4P
--HG--
extra : rebase_source : dfaf13fb4c2185985f4f074c338ccf1fef8f3c94
Bug 1295053 removed most uses of NS_METHOD and NS_CALLBACK, but one use was
unintentionally left behind (in the XPIDL parser) and another has since crept
in (in MediaDrmCDMProxy.h).
So this patch removes NS_METHOD and NS_CALLBACK. NS_METHOD_(nsresult) and
NS_CALLBACK_(nsresult, T) can still be used for the same purpose, but those
alternatives are less likely to be used unintentionally.
--HG--
extra : rebase_source : a50fc7b2a64a36d1ca9beda81bc0edb8f2ec1934
NS_LogCOMPtrAddRef and NS_LogCOMPtrRelease always pass false to
GetSerialNumber, because they pass in everything they get without
regard to whether it is being logged or not, so they don't want to
create a serial number if none exists. This causes the assertions
added in bug 1309051 to be hit. To work around this, I hoist the
assertion into the other callers of this method. Two of them already
had this check, but it was non-fatal.
This also makes the asserts not happen in release builds, as I decided
it doesn't really matter what happens if somebody tries to use it
there.
--HG--
extra : rebase_source : 5e70290492fd442b79b4d40c300a263e322f485b
With the added safety checks it's unlikely that anything in this function will
fire ObjC exceptions, but our rule is to have guards around every Objective C
function that can directly be called from C++ files.
MozReview-Commit-ID: GQ0bN5638Sf
--HG--
extra : rebase_source : 3919f4a2b8160f197e1690ba13b58319239848e1
extra : source : 3d233eddd929e0cb2cadf0b07f75d60aa3fba419
This potentially changes behavior. On my machine, the old code returned
NS_ERROR_FAILURE because the dictionary did not have a "countryCode" entry,
but this new implementation correctly returns the string "CA".
MozReview-Commit-ID: 17Vme0fcAIw
--HG--
extra : rebase_source : 9ffc388ae98b11cb37c37957a8721e92284208c3
extra : source : e1a14b0c638571ec7f7aaec56f11d4b77dfb4dd5
NS_FOUND_TARGET is now declared as an error code. However, making it as a success code makes the code simpler.
First, this patch renames it to NS_SUCCESS_EDITOR_FOUND_TARGET because it's usual naming rule (according to the other declarations).
Next, FindTargetNode() should return it when a nest call of itself returns NS_SUCCESS_EDITOR_FOUND_TARGET as it does now.
Finally, removing the code overwriting NS_FOUND_TARGET with NS_OK from HTMLEditor::CreateDOMFragmentFromPaste() since it doesn't cause hitting NS_ENSURE_SUCCESS() and the variable, rv, will be overwritten with other method's result.
MozReview-Commit-ID: 6GgZptrXXQa
--HG--
extra : rebase_source : 79418fc83fb087e559221f895c59c7c334980456
This is an unrelated change to fix an issue that was bothering me.
MozReview-Commit-ID: Cxw9WhHfSAf
--HG--
extra : rebase_source : 10e3b3f28ecad0af216dbb368ffdb3b0ff75c7f9
Nobody asks for the new stats, only the total ones, so there's no need
for two sets of statistics.
MozReview-Commit-ID: AO0ue9MPn3N
--HG--
extra : rebase_source : 8d5237c4efdc0ece5bf1a386cae38e394aaadf01
Only about:bloat used NEW_STATS, so act like we have ALL_STATS
everywhere. A later patch will remove the mNewStats field.
MozReview-Commit-ID: LUJBpS3iYht
--HG--
extra : rebase_source : 543951314e12e7964e3f25c155b658d50ce674a6
DumpStatistics does not track any objects that are created or
destroyed while it is running, which means that any subsequent calls
to it will produce incorrect results. This can lead to incorrect
positive or negative leaks being reported. See 1271182.
Now that about:bloat has been removed, DumpStatistics should only be
called once, during shutdown.
MozReview-Commit-ID: IjMkExeBRBr
--HG--
extra : rebase_source : 5966789c2febfedc796d17f8589e8c3703d266cb
* Only allows setting the log file at runtime if not set by an Env Var
* LogModulePrefWatcher will watch logging.config. prefs and call into Logging.cpp to set the log file, sync or timestamp
* Log files set by pref will have a -main.PID or -child.PID suffix
* If the logging.config.clear_on_startup pref is true, prefs will be reset upon restart.
MozReview-Commit-ID: CWJujX4jm2A
We skip running shutdown collection on the main thread, because we're
exiting right after, but the process still continues when we shut down
a worker, so we should always do collections there.
MozReview-Commit-ID: IQZItm1qWXW
--HG--
extra : rebase_source : 4fd89e36db124a524c240e806a885dee3b68979e
For testing purposes it will be useful to be able to trigger crashes in Rust
code. Being able to trigger a panic seems like a good place to start. This
will make it easier to validate improvements in crash reporting.
MozReview-Commit-ID: Bh5rBieLLWW
--HG--
rename : toolkit/crashreporter/test/unit/test_crash_moz_crash.js => toolkit/crashreporter/test/unit/test_crash_rust_panic.js
extra : rebase_source : 7cfc08e62de49de869b97ae96630db573f882f18
This change avoids lots of false positives for Coverity's CHECKED_RETURN
warning, caused by NS_WARN_IF's current use in both statement-style and
expression-style.
In the case where the code within the NS_WARN_IF has side-effects, I made the
following change.
> NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
> -->
> Unused << NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
In the case where the code within the NS_WARN_IF lacks side-effects, I made the
following change.
> NS_WARN_IF(!condWithoutSideEffects);
> -->
> NS_WARNING_ASSERTION(condWithoutSideEffects, "msg");
This has two improvements.
- The condition is not evaluated in non-debug builds.
- The sense of the condition is inverted to the familiar "this condition should
be true" sense used in assertions.
A common variation on the side-effect-free case is the following.
> nsresult rv = Fn();
> NS_WARN_IF_(NS_FAILED(rv));
> -->
> DebugOnly<nsresult rv> = Fn();
> NS_WARNING_ASSERTION(NS_SUCCEEDED(rv), "Fn failed");
--HG--
extra : rebase_source : 58788245021096efa8372a9dc1d597a611d45611
Bug 1263355 changed scopes from JSObjects (which are represented in
the CC graph) to a new kind of GC thing. Many objects can share the
same scope, so they will end up calling the scope trace method
repeatedly, causing cycle collections to become much slower in some
cases.
MozReview-Commit-ID: CFO87zXjwgu
