Closed Bug 1509972 Opened Last year Closed Last year

Reduce nsAutoPtr usage in layout/base


(Core :: Layout, enhancement, P3)




Tracking Status
firefox65 --- fixed


(Reporter: dholbert, Assigned: dholbert)



(5 files)

UniquePtr is preferred over nsAutoPtr these days.

Filing this bug on making the switch in several places in layout/base.
This patch also gives nsCSSFrameConstructor.h its own UniquePtr include (since
we have some UniquePtr usage there, but no include).  Presumably it's already
getting the include indirectly (via some other header) right now, but it should
really include it directly if it uses the type directly.

(This leaves one nsAutoPtr usage in nsCSSFrameConstructor, for 'mNode'. We can
probably convert that one without too much trouble, but I'm not doing so yet,
in part because we intentionally leak that variable in one spot and I haven't
fully worked out the ownership transfer for that case.)
In each file touched by this commit, there were no mentions of nsAutoPtr
besides the #include.

I verified that the folder layout/base still builds successfully in
non-unified mode after this patch, too. So, none of these files are secretly
using nsAutoPtr and depending on some other .cpp file to provide the header.
(I accidentally posted part 5 on its own before the other parts, so it's listed first here on bugzilla; but it's ordered correctly in the phabricator stack.)
Pushed by
part 1: Remove unnecessary nsAutoPtr includes from files in layout/base. r=TYLin
part 2: Use UniquePtr (not nsAutoPtr) to store nsPresContext members mTextPerf and mMissingFonts. r=TYLin
part 3: Use UniquePtr (not nsAutoPtr) for mNext pointers in StaticPresData's "LangGroupFontPrefs" list. r=TYLin
part 4: Use UniquePtr (not nsAutoPtr) to store nsDocumentViewer member mAutoBeforeAndAfterPrint. r=TYLin
part 5: Use UniquePtr (not nsAutoPtr) to store a few local vars in nsCSSFrameConstructor. r=TYLin
You need to log in before you can comment on or make changes to this bug.