This conversion was done with the script:
find . -name '*.cpp' -o -name '*.h' -o -name '*.mm' -o -name '*.idl' | \
egrep -v 'cairo-win32-refptr.h|RefPtr.h|TestRefPtr.cpp' | \
xargs sed -i -e 's/mozilla::TemporaryRef</already_AddRefed</g' \
-e 's/TemporaryRef</already_AddRefed</g'
Manual fixups were performed in the following instances:
- We handled mfbt/RefPtr.h manually so as to not convert TemporaryRef itself
into already_AddRefed.
- The following files had explicit Move() calls added to make up for the lack
of a copy constructor on already_AddRefed:
dom/base/ImageEncoder.cpp
dom/media/MediaTaskQueue.{h,cpp}
dom/media/webaudio/PannerNode.cpp
- A redundant overload for MediaTaskQueue::Dispatch was deleted.
- A few manual fixups were required in mfbt/tests/TestRefPtr.cpp.
- Comments, using declarations, and forward declarations relating to
TemporaryRef in dom/canvas/ and gfx/layers/ were changed to refer to
already_AddRefed.
CLOSED TREE
Backed out changeset 12ce98475c6e (bug 1119980)
Backed out changeset bdb8d05f8870 (bug 1119980)
Backed out changeset a68a18840492 (bug 1119980)
Having this implicit conversion means that we can silently do extra
refcounting when it's completely unnecessary. It's also an obstacle to
making RefPtr more nsRefPtr-like, so let's get rid of it.
Note that the analysis currently just looks at the AST subtree of the
function call site and is therefore unable to correctly deal with cases
such as the last two hunks of the change to OggCodecState.cpp. Fixing
the analysis to deal with that would be very difficult, so we currently
adjust the code so that it compiles. The first hunk in that file though
is a real bug that this analysis found.
Note that the analysis currently just looks at the AST subtree of the
function call site and is therefore unable to correctly deal with cases
such as the last two hunks of the change to OggCodecState.cpp. Fixing
the analysis to deal with that would be very difficult, so we currently
adjust the code so that it compiles. The first hunk in that file though
is a real bug that this analysis found.
--HG--
extra : rebase_source : b44bb6d90d95551d860e0b5a1afcf2bb35cde084
There are, sadly, many combinations of linkage in use throughout the tree.
The main differentiator, though, is between program/libraries related to
Gecko or not. Kind of. Some need mozglue, some don't. Some need dependent
linkage, some standalone.
Anyways, these new templates remove the need to manually define the
right dependencies against xpcomglue, nspr, mozalloc and mozglue
in most cases.
Places that build programs and were resetting MOZ_GLUE_PROGRAM_LDFLAGS
or that build libraries and were resetting MOZ_GLUE_LDFLAGS can now
just not use those Gecko-specific templates.
