This is straightforward mapping of PR_LOG levels to their LogLevel
counterparts:
PR_LOG_ERROR -> LogLevel::Error
PR_LOG_WARNING -> LogLevel::Warning
PR_LOG_WARN -> LogLevel::Warning
PR_LOG_INFO -> LogLevel::Info
PR_LOG_DEBUG -> LogLevel::Debug
PR_LOG_NOTICE -> LogLevel::Debug
PR_LOG_VERBOSE -> LogLevel::Verbose
Instances of PRLogModuleLevel were mapped to a fully qualified
mozilla::LogLevel, instances of PR_LOG levels in #defines were mapped to a
fully qualified mozilla::LogLevel::* level, and all other instances were
mapped to us a shorter format of LogLevel::*.
Bustage for usage of the non-fully qualified LogLevel were fixed by adding
|using mozilla::LogLevel;| where appropriate.
This is straightforward mapping of PR_LOG levels to their LogLevel
counterparts:
PR_LOG_ERROR -> LogLevel::Error
PR_LOG_WARNING -> LogLevel::Warning
PR_LOG_WARN -> LogLevel::Warning
PR_LOG_INFO -> LogLevel::Info
PR_LOG_DEBUG -> LogLevel::Debug
PR_LOG_NOTICE -> LogLevel::Debug
PR_LOG_VERBOSE -> LogLevel::Verbose
Instances of PRLogModuleLevel were mapped to a fully qualified
mozilla::LogLevel, instances of PR_LOG levels in #defines were mapped to a
fully qualified mozilla::LogLevel::* level, and all other instances were
mapped to us a shorter format of LogLevel::*.
Bustage for usage of the non-fully qualified LogLevel were fixed by adding
|using mozilla::LogLevel;| where appropriate.
Now that we don't have to worry about XPCShellErrorReporter being invoked at
weird times, we can get rid of this nastiness - though it unfortunately means
getting rid of one of my best comments in the tree. :-(
This change introduces a minor regression: exceptions thrown during result
stringification will trigger the error reporter (since there's no script on
the stack), which will cause XPCShell to return a runtime error. The fix for
this problem is to mark the AutoJSAPI as taking ownership of error reporting,
which will prevent SpiderMonkey for playing the error-reporting guessing game.
That will happen further on in this patch stack, so I'm not going to worry about
it for now.
Backed out changeset 21e041962894 (bug 1155898)
Backed out changeset e42c9f4794d9 (bug 1155898)
Backed out changeset 7ef9cce1a775 (bug 1155898)
CLOSED TREE
They're not needed now that there is (temporarily) PLDHashTable2, which has an
initializing constructor and a destructor.
--HG--
extra : rebase_source : 78d3eeb326935ad7a19e3bdf9b2092eb2a4208a7
We can't call JS code while iterating over the JS heap in the JS memory
reporter. The Yandex Elements add-on is causing this in two cases.
- The add-on implements some nsIURI objects. This one's easy to work around,
because GetLocation() can just skip any JS-implemented nsIURI objects.
- The add-on implements some nsIProtocolHandler objects in order to
implement a custom "xb://" scheme. This one is harder to workaround because
the call to the JS object's method occurs deep within NS_NewURI(), well
beyond the JS reporter code. So we just skip "xb://" URLs.
--HG--
extra : rebase_source : 8184c6d9152ee416575689c221bd77b6e0227412
Due to Android startup regressions (bug 1163066) and plugin crashes (bug
1165155).
--HG--
extra : rebase_source : 380f79e67dff4c4eaa2614f286a4d0669666b652
Various parts of the first half of BeginCollection() can start an incremental GC.
This is bad because running the GC and CC at the same time can cause the CC to end
up with pointers to dead JS objects.
To avoid this, we finish any incremental GC in progress in BeginCollection. This
is slow, but hopefully it is rare.
