Closed Bug 1522208 Opened 1 year ago Closed 1 year ago

Some files in dom/svg have a nsCOMPtr include but no usages, or vice versa


(Core :: SVG, defect, P3)




Tracking Status
firefox66 --- fixed


(Reporter: dholbert, Assigned: dholbert)




(1 file)

When reviewing bug 1522159, I noticed a file (DOMSVGAnimatedLengthList.cpp) which #includes nsCOMPtr.h but doesn't have any usages of the nsCOMPtr<> type.

I suspect this file really just needs an include for RefPtr.h (because it does have a bunch of RefPtr<> instances).

Filing this bug on this & other files in dom/svg that have nsCOMPtr header but no usages, & vice versa.

Here are the commands I'm using to find these:

grep nsCOMPtr dom/svg/*.* | cut -f1 -d':' > /tmp/matches.txt
for x in `cat /tmp/matches.txt | uniq`; do \
  count=`grep $x /tmp/matches.txt | wc -l`; \
  echo $count $x; done | grep "^1"

That yields the following results (all files that have a single mention of the string "nsCOMPtr", whether that mention is a header or a usage):

Many/most of these files probably really want #include "mozilla/AlreadyAddRefed.h" if that's the only refcounting type they use (as is the case for e.g. SVGAngle.h I think) -- or #include "mozilla/RefPtr.h" if they use RefPtr&lt;> (as is the case for e.g. DOMSVGAnimatedLengthList.cpp)

Assignee: nobody → dholbert

A lot of files include nsCOMPtr without really needing it in dom/svg. (And a
few files use the nsCOMPtr type without including its header.)

For this patch, I found candidate files by just searching for files that only
had a single line that contained "nsCOMPtr", and I took the following actions:

  • If the match is an #include, then remove it (replacing it with the include
    for RefPtr or AlreadyAddrefed if the file uses those types instead).
  • If the match is a usage of the type, then add an #include for nsCOMPtr (as
    well as one for RefPtr, if the file uses that type).

(And in a few cases, I moved an adjacent #include, to get the #include list
closer to sortedness.)

I verified that the dom/svg directory continues to build successfully in
non-unified mode (i.e. if I remove UNIFIED_ from its file). So, I'm
not removing any includes that files are now inadvertantly leaning on other
compilation units to provide.

Pushed by
Clean up nsCOMPtr.h includes in dom/svg. r=longsonr
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
You need to log in before you can comment on or make changes to this bug.