I want the EME device binding/nodeId code to be callable from gtests, as well
as in plugin-container. I need this because I want to add a gtest that ensures
that we don't regress the EME/GMP device binding code. I want to call the GMP
device binding code in the gtest and in the GMP process, and compare the
result.
So we need to make it possible to link the device binding code into the gtests
as well as plugin-container. So move all code that device binding calls into
librlz, to make it easier to link against all the code required.
Note: the device binding code needs to be statically linked into
plugin-container so that it's covered by the Adobe CDM's voucher tool.
MozReview-Commit-ID: AvBAe1dh49Z
--HG--
rename : ipc/app/sha256.c => dom/media/gmp/rlz/sha256.c
rename : ipc/app/sha256.h => dom/media/gmp/rlz/sha256.h
extra : rebase_source : f60f1e68649fa90cbe1f2fe09f5f69948444b1df
I want the EME device binding/nodeId code to be callable from gtests, as well
as from in plugin-container.
First step is to move the device binding code into a discrete file, so I can
also link that into gtests, and call it from there to compare the result with
what's in the GMP process.
MozReview-Commit-ID: 9xT2rp3hWW
--HG--
extra : rebase_source : 824c7a9841bce83c438decad48ce210f6c2a5571
The original changeset that is being backed out had comment:
Bug 1023941 - Part 2: Static-link the CRT into plugin-container.exe.
MozReview-Commit-ID: 1iPJghgd0t2
--HG--
extra : rebase_source : cbed4e43f51af8ea0c3adbfc150ed029fe0d0f57
The OnSessionClosed() callback is happening on a timer, after
WidevineDecryptor::DecryptingComplete() has been called. So mCallback could
actually be non-null because DecryptingComplete() has been called, but the
object pointed to by mCallback has been deallocated, and mCallback is a
dangling pointer.
MozReview-Commit-ID: 4xdHYRn7EAS
--HG--
extra : source : 55d79997aa3e3e2133d9155c37f4435317b44061
Now that GMPParent detects whether gmp-clearkey can decode using AAC/H.264
using WMF before reporting gmp-clearkey's GMPParent can decode AAC/H.264, we
don't need the GMPDecryptorCallback::SetCapabilities() callback from the GMP to
signal to the PDMFactory that the GMP can decode. We can now trust what the
GMPService tells us.
So we can remove the "waiting for CDM caps" step in the state machine's startup
sequence. And all the plumbing. :)
If we need more caps, like for an decode-and-render path, we can declare those
as API strings in the info file.
MozReview-Commit-ID: E0QhU4cYhjo
--HG--
extra : rebase_source : 7d15ab6a45bac88c15c053f416d941b5fe0807b0
We've observed some crashes derefing the callback pointer, which may be
occuring due to shutdown happening before init has setup the callback pointer.
MozReview-Commit-ID: JsOqfjejMVI
--HG--
extra : rebase_source : e175dd8556ad50316bc16232782e593eea3e2ec8
GeckoMediaPluginService::mAbstractThread was not reset as expected from
ShutdownGMPThread, meaning it would retain a reference to the GMP thread, and
it would allow dispatch attempts to the GMP thread after shutdown.
Also mAbstractThread was not protected by a mutex (as mGMPThread was), which is
definitely needed now that it can be reset at shutdown time.
As its prefix implies, GetAbstractThread could return a nullptr, so it should
be checked before every use.
Note that this GetAbstractThread call (and its check) has been moved closer to
the start of functions using it, to avoid unnecessary and potentially invariant-
breaking partial work to take place when we can know in advance that it won't
fully succeed because the GMP thread is not available.
MozReview-Commit-ID: B1drOeM65hr
--HG--
extra : rebase_source : 1d389c663e26a25035bf2aa22b2cca478ef954fe
In bug 1264497 we discovered that Netflix was broken because we'd made a change
to not send the Adobe GMP the device bound nodeId, which it stored in GMP
storage. When the GMP was comparing the nodeId it had stored against what it was
passed (nothing) the comparison was failing. Users could have worked around this
problem by clearing their GMP storage, whereupon the Adobe GMP will have stored
"nothing" as its nodeId.
When bug 1264497 was fixed, users who'd cleared their storage will see Netflix
fail again, as their stored nodeId of "nothing" will again not match what we
pass in. So to fix Netflix for these users, we need to clear GMP storage.
This is another instance of a more general problem that we have occasionally
encountered, namely that sometimes GMP storage becomes incompatible, and we
need to clear it. Having a general mechanism that we can use to clear storage
remotely will be helpful, so this patch adds one, and triggers it to fire.
This mechanism is pref controlled, so that we can issue a hotfix if necessary
to clear GMP storage.
MozReview-Commit-ID: GzSyBj0P2JG
--HG--
extra : rebase_source : b854860ee533b0742a664c862278ce54c9052596
Assert that the CDM wrapper is given a non-null CDM pointer.
(so GetCDM() doesn't need to be null-checked.)
Renamed WidevineVideoDecoder mCDM to mCDMWrapper, to avoid (my) confusion.
Assert that WidevineVideoDecoder is given a non-null CDM-wrapper pointer.
Assert that WidevineVideoDecoder only accesses the CDM before DecodingComplete.
Small optimization: Move aCDM into mCDM (to save an AddRef/Release pair).
MozReview-Commit-ID: yKupY067ly
--HG--
extra : rebase_source : 94140b423a04f28368de0831761406c145fad93e
Check the return result from Widevine's CDM creation function, and handle
failure.
MozReview-Commit-ID: HYvKgdK53aQ
--HG--
extra : rebase_source : b3e28ba5e0020e3a6dd77c8a83b58be233fdc770
Ensure that there is a CDM before creating a video decoder that relies on that
CDM. This is mainly to prevent using the Widevine video decoder alone, without
decryption.
MozReview-Commit-ID: 7p49CnmV2r7
--HG--
extra : rebase_source : 49b07100b2be56584bc14f41d39d4872f0539c3a
If you request a GMPParent with a nodeId, you should get any already running
instances with the same nodeId in preference to cloning an existing GMP and
assigning it the nodeId.
This is ensures that EME GMP actors that are same-origin run in the same GMP
instance.
The GMP gtests are failing because of the cross-origin checks in
GeckoMediaPluginServiceParent::SelectPluginForAPI(). The loop there selects the
first GMPParent that can be used from the nodeId passed in. We previously
assumed a GMPParent can be used from a nodeId if the GMPParent has the same
nodeId, or if it has not loaded its process and it has no nodeId. The problem
with assuming that, is if an in-use GMPParent with the target nodeId lies in
the GeckoMediaPluginServiceParent::mPlugins list after a GMPParent with no
nodeId, we'll end up using the first GMPParent (the one with no nodeId) rather
than the one with the target nodeId.
The solution is to change GeckoMediaPluginServiceParent::SelectPluginForAPI()
so that effectively if we have a target nodeId, we'll select the first
GMPParent that has the same nodeId, or we'll clone the first which supported
all the requested capabilities/tags.
This means when you request a GMPParent with a given nodeId, you'll get the one
with the same nodeId (origin) by preference.
MozReview-Commit-ID: 4yVnrO8B1Pg
--HG--
extra : rebase_source : 5db7c6ef5f360df7d2244ca828b68b340c4e9a41
Prior to this change, we'd store the GMPStorage records for private browsing
sessions in the GMPStorageParent. The problem with this is that they only have
a lifespan matching their corresponding GMPParent. This means that if a GMP
stores something in a PB session, and the GMP is shutdown and then re-created,
we are likely to loose the stored data. This could mean that the PB session
gets results it doesn't expect, and thus expose a way for PB mode to be
detected.
MozReview-Commit-ID: 1OMD0LvidYs
--HG--
extra : rebase_source : 75661a7b1717e39a29c3e12ad203d9273e8485ab
The GMP which GeckoMediaPluginServiceParent::FindPluginForAPIFrom() returns
depends on the order in which GMPs lie in GMPServiceParent::mPlugins. However
when we shutdown a GMPParent we remove and then re-append the GMPParent to
mPlugins. This means the order in which GMPs lie in the list changes.
So when WebRTC requests an H.264 decoder, the first time it will get OpenH264,
since that's first in the list. But once we dispose of that decoder, its
GMPParent will be cloned and the clone will be appended to the end of the
list. This means the next time WebRTC requests a decoder, it'll get whatever
was next in the list.
This could be the Adobe GMP, which seems to be able to handle whatever WebRTC
is putting into it. However, if you do this enough times, you'll get the
Widevine CDM, which can't handle whatever WebRTC is putting into it.
So a quick hack to fix this is in ReAddOnGMPThread is to re-insert the clone
of the GMP into the slot in mPlugins that the original occupied. Then WebRTC
will always get OpenH264 whenever it requests for an H.264 decoder, as the
order of the GMPParents in mPlugins won't change.
MozReview-Commit-ID: Ii4AMqDqAo9
--HG--
extra : rebase_source : 62c10bc5b77ef259917aa6c88309be2423c93914
Crash reporting for GMPs being used from the EME call site are not generating
crash reports because they depend on the MediaKeys object calling
GMPService::AddPluginCrashHandler() to associate a window to which the
PluginCrashedEvent is fired. This doesn't work with e10s enabled because the
GMPParent which causes the plugin crash handlers to run is in the chrome
process, but the MediaKeys which adds the handler is in the child process. So
the crash handler is on the GMPServiceChild, but we only run the crash handlers
that were added to the GMPServiceParent in the chrome/parent process.
The solution is to broadcast a message from the chrome process to all the
content processes when a GMP has crashed that causes the GMPServiceChild to
also run its crash handlers.
MozReview-Commit-ID: 8Lek16G9ZGb
--HG--
extra : rebase_source : 180691046812df474ea33324d2b98ac71d11c9cd
The WMF HasAAC/HasH264 checks were done off the main thread, as soon as the
plugin was loaded, which was way too soon in the overall startup process, when
the WMF subsystem may not have been properly initialized yet, or may be in the
middle of it.
The solution here is to delay these checks until they are actually needed to
respond to a format-support request, as they come later in the process.
Note: This may not be the ideal solution yet, as we are still relying on some
magic sequencing of events. Other avenues have been explored unsuccessfully
yet, but we may want to revisit this issue after this urgent patch has landed.
MozReview-Commit-ID: JVgINc5FLFx
--HG--
extra : rebase_source : 3d02570ed26043d050d4848d968e3c673b35f5c3
Now that adding GMPs to the GMP service is async under the hood, for safety
the GeckoMediaPluginServiceParent needs to expose when adding a GMP
has finished so that things that depend on GMPs being present can be reliable.
For example, the call to GMPDecoderModule::UpdateUsableCodecs() that happens
at the end of AddPluginDirectory depends on the GMPs being up to date, so it
needs to happen after the add has finished.
MozReview-Commit-ID: Fn8b0GNILNg
This means we wait for the GMP service to have finished detecting all available
GMPs from the environment before we start creating GMP actors. Without this, we
get gtest failures due to gtests trying to create GMP actors before the async
GMPServiceParent::LoadFromEnvironment() has completed, i.e. we fail to create
actors because we've not had a chance to setup the GMPParent capabilities yet.
MozReview-Commit-ID: Hl4o1c4QthJ
This makes it easier to chain promises returned by GMPParent::Init() with calls
to GMPServiceParent::LoadFromEnvironment() in the next patch.
MozReview-Commit-ID: KdGVvzAedJW
XPCOMThreadWrapper::GetCurrent() is failing because it's not keeping
AbstractThread::sCurrentThreadTLS up to date. This causes assertion failures
during startup of the GMP stack when dispatching via InvokeAsync to the GMP
thread, which is an XPCOM thread wrapped by the XPCOMThreadWrapper.
We can trivially initialize AbstractThread::sCurrentThreadTLS to be the
XPCOMThreadWrapper on the target thread, since it's thread-local-storage, and
the target thread won't change.
MozReview-Commit-ID: EIEFZppR2PS
The Widevine CDM does not have an AAC decoder. It can however decrypt audio
streams. It's our policy to not decode AAC streams decrypted by the Widevine
CDM with the Adobe GMP's unencrypted decoding functionality. So reject
MediaKeySystemAccess requests for Widevine if we don't have a system AAC
decoder that we can use.
MozReview-Commit-ID: Ltq52wT1qno
The logic in MediaKeySystemAccess is convoluted because it needs to keep
checking whether we're servicing a clearkey request and whether WMF is
available for gmp-clearkey to decode with. If we instead push those checks down
into GMPParent at the time where we parse the GMP info file, we can just not add
the decode capability to the GMPParent, and can remove the special cases in
MediaKeySystemAccess. This simplifies adding the (similar) special cases for
Widevine in the next patch.
MozReview-Commit-ID: IKD5LU86zIv
This means we won't try to build it when ac_add_options --enable-eme=widevine is
not present, and critically, we won't try to build it on Android, since the Chromium
Widevine plugin isn't available there.
MozReview-Commit-ID: 1jQvAbJP8HG
We need to not build Widevine by default, and when enabled we will need to be able to
ifdef on MOZ_WIDEVINE_EME (see next patch) so that we can not build the code on platforms
where it can't possibly work (Android specifcally, as Widevine isn't available as a
Chromium plugin there).
MozReview-Commit-ID: Avgz5NRcl9v
This ensures that we don't try to use one GMP instance to service multiple same-origin MediaKeys'
CDM access, as the Widevine CDM's Chromium interface is synchronous, so it doesn't handle running
multiple decoders well. Multiple same-origin GMPs can't safely use the same storage concurrently,
but thankfully Widevine doesn't require persistent storage, so we can just disallow that entirely
and avoid the problem.
MozReview-Commit-ID: 78I4IIGgHRA
This means that when initializing the Widevine CDM, we will be able to asynchronously
parse its manifest.json on the main thread, as the WebIDL JSON parser only runs there.
MozReview-Commit-ID: GI1sc4x4m16
I need to make GMPParent::Init() async, because the WebIDL JSON parsing
must happen on the main thread, and GMPParent::Init() is called on the
GMP thread, so I need GMPParent::Init() to be async so that in the
Chrome manifest case it can dispatch a task to the main thread to parse
the Chrome manifest before completing. So I'll make GMPParent::Init()
return a promise, and to do that, I need the GMP thread to have an
AbstractThread wrapper.
MozReview-Commit-ID: 44b4Z4jpar8
Add a GMPAdapter implementation that adapts the Widevine Chrome CDM to
the GeckoMediaPlugin API. We're still allocating memory for video frames
in non shmem buffers, and copying them over to a shmem before returning
them to Gecko, we can fix that at a later date. I hook this adapter up
in a later patch in the series.
MozReview-Commit-ID: 7iSFODVWPu3
Some encrypted MP4 files lack subsample info for some samples, so we need this check
to prevent us crashing on such files.
MozReview-Commit-ID: AXqOCAlb7IY
We have nsDependentCString to avoid needless memory traffic here. We
need an explicit cast, however, because we don't have a ParamTraits
specialization for nsDependentCString, only for nsCString, and template
specialization doesn't take derived classes into account.
But make sure that there's no way a GMP can track and report what a user watches using unencrypted decoding.
MozReview-Commit-ID: DljjYjcziRS
--HG--
extra : rebase_source : 1c4204ff69df0ed03015c069736831e5f8b35a29
The only reason we need to parse the info file in the GMP child process
is because we need to read the "Libs:" line so that the child process
can preload DLLs on Windows. We already parse the GMP info file in the
parent process, so we can remove the need to parse it again if we parse
the "Libs" field in the parent, and pass that through to the child.
Without this, existing installs of the Adobe x64 Windows GMP from the zip file
where the GMP files are read-only will not be able to be installed.
--HG--
extra : rebase_source : 21ac7b0e4c55cc26e17f05563f61bdce65117507
UnloadPlugins runs in the GMP thread. While it locks mMutex, any locking
attempt on the main thread would effectively block the main thread while we are
calling CloseActive on each plugin.
The problem is that CloseActive calls GeckoMediaServiceParent::GetSingleton(),
which dispatches a task to the main thread, which may be blocked because of
mMutex.
To solve this inter-locking issue, the list of plugins is first copied to a
local array, after which mMutex may be released, and we may now call
CloseActive without risking locking.
Initialize GMPStorage::mShutdown to true, so that if Init() has not completed
yet or if it failed, other methods will not try and access a null mStorage.
Remove GMPVideoDecoderTrialCreator, and the tests and IPC/IDL supporting it.
--HG--
extra : commitid : HlbJPl2gPAl
extra : rebase_source : fe1773014e5d09da264f85d464e408aca46a60c4
Thanks to bug 1121676, GMPParent does not need to be created and destroyed
on the main thread. Main-thread constraints have been removed.
Also, this means that GeckoMediaPluginServiceParent::ClonePlugin() and
AddOnGMPThread (running on the GMP thread) do not need to sync-dispatch the
creation on the main thread.
This should remove the deadlock that prevents
GeckoMediaPluginServiceParent::UnloadPlugins() from running on the GMP thread.
To allow GMPs time to update to new GMPDecryptor versions, we support the
latest GMPDecryptor version, and the previous.
In order to support a consistent interface to Gecko, we adapt the previous
GMPDecryptor version to the latest in the GMP child process. So Gecko always
thinks it's talking to the latest version.
We also make gmp-fake deliberately support the previous GMPDecryptor version,
to ensure this code path remains tested.
Implemented GetStackAfterCurrentFrame() for Mac, by finding which Mach VM
region contains the stack, then erasing everything between the start of the
region (lowest possible stack address) and the current stack frame pointer.
Having HASH_NODE_ID_WITH_DEVICE_ID #defined is enough for GMPLoader to start
using the Mac version of GetRawMachineId.
Note: The stack (that may contain information gathered during GetRawMachineId)
is not erased, so it could theoretically be possible for a compromised GMP to
find out some sensitive user information. Another bug will deal with this.
Necessary routines were extracted from other files in:
6c3bf03265/
(otherwise a lot of code would have had to be imported, most of which would be
unused anyway.)
These extracted routines were reduced to only the actually-used code.
base::StringPrintf was only used to stringify a few hex values, this particular
use was easier to reimplement in a small loop rather than trying to extract the
whole printf suite.
base::UTF8toUTF16 is not needed, as we just return bytes. So internally a
std::string (containing UTF8) is used and its contents transferred to the
output buffer.
GetRawMachineId was returning its generated data through a 'string16', which on
Windows was conveniently equivalent to a std::wstring.
However on Mac, wstring uses 32-bit characters, so in order to comply with the
string16 interface, a lot of non-trivial code would have to be imported and
vetted.
Also, in the end GMPLoader::Load passes this string16 to SHA256_Update() as a
sequence of bytes, the actual type of the data is lost!
So to simplify this work, GetRawMachineId will now return its data through a
vector of bytes, and the platform-dependent implementations may use whatever
data type they want internally.
The Windows GetRawMachineId actually returns the same data in this vector, so
it stays compatible with the previous code.
This also removes turning off optimization for the Load function. That was an
attempt to fix the side-by-side loading. It may also have helped with ensuring
that the memsets were not optimized, but that has been fixed by Bug 1208892.
In bug 922912, we folded back gkmedias.dll info xul.dll, so in practice, there
is no default configuration left that exercises GKMEDIAS_SHARED_LIBRARY. And
sure enough, it's been broken for months in many different ways.
The gkmedias intermediate library is however kept for webrtc signaling tests.
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
This commit was generated using the following script, executed at the
top level of a typical source code checkout.
# Don't modify select files in mfbt/ because it's not worth trying to
# tease out the dependencies currently.
#
# Don't modify anything in media/gmp-clearkey/0.1/ because those files
# use their own RefPtr, defined in their own RefCounted.h.
find . -name '*.cpp' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
grep -v 'mfbt/RefPtr.h' | \
grep -v 'mfbt/nsRefPtr.h' | \
grep -v 'mfbt/RefCounted.h' | \
grep -v 'media/gmp-clearkey/0.1/' | \
xargs perl -p -i -e '
s/mozilla::RefPtr/nsRefPtr/g; # handle declarations in headers
s/\bRefPtr</nsRefPtr</g; # handle local variables in functions
s#mozilla/RefPtr.h#mozilla/nsRefPtr.h#; # handle #includes
s#mfbt/RefPtr.h#mfbt/nsRefPtr.h#; # handle strange #includes
'
# |using mozilla::RefPtr;| is OK; |using nsRefPtr;| is invalid syntax.
find . -name '*.cpp' -o -name '*.mm' | xargs sed -i -e '/using nsRefPtr/d'
# RefPtr.h used |byRef| for dealing with COM-style outparams.
# nsRefPtr.h uses |getter_AddRefs|.
# Fixup that mismatch.
find . -name '*.cpp' -o -name '*.h'| \
xargs perl -p -i -e 's/byRef/getter_AddRefs/g'
A lot of existing code has variations on:
if (ManagedPFooChild().Length()) {
...(ManagedPFooChild()[0])...
}
// Do something with nullptr, or some other action.
It's pretty reasonable to repeat this code when the managed protocols
are stored in an array; the code gets much less nice when managed
protocols are stored in a hashtable. Let's write a small utility
function to handle those details for us. Then when we change the
underlying storage, we only need to update this function, rather than a
bunch of callsites.
ProtocolUtils.h is included by all the generated IPDL headers, so
LoneManagedOrNull should be available everywhere the above pattern would
be encountered.
This is found by Viva64. Because the data we're memsetting to 0
may not be used after this point, the compiler can eliminate the
memsets. We need to roll our own inline memset that cannot be
optimized away.
These are all conditional uses of ALLOW_COMPILER_WARNINGS=True that are no
longer necessary.
--HG--
extra : rebase_source : e654fa940aed18b1d5ef7b2bebb45bbef59cfd84
The patch removes 455 occurrences of FAIL_ON_WARNINGS from moz.build files, and
adds 78 instances of ALLOW_COMPILER_WARNINGS. About half of those 78 are in
code we control and which should be removable with a little effort.
--HG--
extra : rebase_source : 82e3387abfbd5f1471e953961d301d3d97ed2973
The bulk of this commit was generated by running:
run-clang-tidy.py \
-checks='-*,llvm-namespace-comment' \
-header-filter=^/.../mozilla-central/.* \
-fix
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.
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.
When a method returns type D derived from RefCounted type B, there is an
ImplicitCastExpr (or an ExplicitCastExpr, if there is an explicit cast
to the base type in the code) in the AST between the CallExpr and
MemberExpr, which we didn't take into account before. This caused the
analysis to not work on common patterns such as
nsCOMPtr<nsIXPCOMInterface>.
When a method returns type D derived from RefCounted type B, there is an
ImplicitCastExpr (or an ExplicitCastExpr, if there is an explicit cast
to the base type in the code) in the AST between the CallExpr and
MemberExpr, which we didn't take into account before. This caused the
analysis to not work on common patterns such as
nsCOMPtr<nsIXPCOMInterface>.
This patch was generated by a script. Here's the source of the script for
future reference:
find . \( -iname "*.cpp" -o -iname "*.h" \) | \
xargs -n 1 sed -i "s/nsRefPtr<nsIRunnable>/nsCOMPtr<nsIRunnable>/g"
Bill McCloskey
Chris Pearce
Bob Owen
Chris Peterson
Kyle Huey
Jean-Yves Avenard
Gerald Squelart
JW Wang
Haik Aftandilian
Jim Mathies
Carsten "Tomcat" Book
Peter Chang
George Wright
Nathan Froyd
Aidin Gharibnavaz
Birunthan Mohanathas
Phil Ringnalda
Nicholas Nethercote
Randell Jesup
Nathan Froyd
Mike Hommey
Ehsan Akhgari
sajitk
Wes Kocher
Sotaro Ikeda
Nigel Babu
Edwin Flores
Edwin Flores
Jacek Caban
Kilik Kuo
Juan Gomez
Ryan VanderMeulen
Ethan Hugg
Eric Rahm
Hieu Le
Steven Michaud
Mike Conley
Andrea Marchesini
Daniel Holbert
Peter Van der Beken
Gerald Squelart
Stephen Pohl
Matthew Gregan