SkPDF: SkBitSet gets reset() to make drop() better.

src/pdf/SkPDFFont.cpp

Index: src/pdf/SkPDFFont.cpp
diff --git a/src/pdf/SkPDFFont.cpp b/src/pdf/SkPDFFont.cpp
index 89c7951f6356b0671afec5b102f67b4521ba500d..d036b80448de50fc1c44d0853c0d1b6b7d7cad9b 100644
--- a/src/pdf/SkPDFFont.cpp
+++ b/src/pdf/SkPDFFont.cpp
@@ -727,5 +727,6 @@ bool SkPDFFont::CanEmbedTypeface(SkTypeface* typeface, SkPDFCanon* canon) {
 
 void SkPDFFont::drop() {

[bungeman-skia, 2016/09/19 17:07:07]

Now I'm wierded out about this 'drop' method which I wan't previously familiar
with. This looks essentially like a destructor (it's even necessary to call
<super>::drop()), and after calling it the object is a bit of a zombie, is it
not (it's kinda in a moved-from state)?

The only real caller appears to be the SkPDFObjectSerializer which is very
obliquely moving all the data out of the PDFObjects it serializes (essentially
making them no longer valid, but also stating that they won't be used again). It
seems to 'drop' them instead of just deleting them because some other structure
(the canon?) may be holding on to these now zombie objects (without a good
reason I can tell) just so they can then be deleted later.

I'd rather see that logic cleaned up than have it leak out and start infecting
the SkBitSet class. It seems like the use of 'drop' (on a reference counted
object) is just asking for difficult to find bugs.

     fTypeface = nullptr;
+    fGlyphUsage.reset();

[bungeman-skia, 2016/09/19 17:07:07]

If this guy is really gone maybe just destruct?

     this->SkPDFDict::drop();
 }