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

src/pdf/SkPDFFont.cpp

 /*
  * Copyright 2011 Google Inc.
  *
  * Use of this source code is governed by a BSD-style license that can be
  * found in the LICENSE file.
  */
 
 #include "SkData.h"
 #include "SkGlyphCache.h"
 #include "SkPaint.h"
@@ skipping 707 matching lines @@
                         this->firstGlyphID(), this->lastGlyphID());
 }
 
 ////////////////////////////////////////////////////////////////////////////////
 
 bool SkPDFFont::CanEmbedTypeface(SkTypeface* typeface, SkPDFCanon* canon) {
     const SkAdvancedTypefaceMetrics* metrics = SkPDFFont::GetMetrics(typeface, canon);
     return metrics && can_embed(*metrics);
 }
 
 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();
 }