[PATCH] D92480: [llvm] Unify interface of (ThreadSafe)?RefCountedBase

[David Blaikie via Phabricator via cfe-commits]

dblaikie added inline comments.


================
Comment at: clang/lib/ASTMatchers/ASTMatchersInternal.cpp:190-196
+// Use a custom deleter for the TrueMatcherInstance ManagedStatic. This prevents
+// an assert firing when the refcount is nonzero while running its destructor.
+struct DynMatcherInterfaceDeleter {
+  static void call(void *Ptr) {
+    static_cast<DynMatcherInterface *>(Ptr)->Release();
+  }
+};
----------------
I think probably the right solution is to have TrueMatcherImpl's dtor Release the same way its ctor Retains. Symmetry is nice/helps avoid splitting this quirk into two different places.


================
Comment at: llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:75-80
+  // Copy and move constructors/assignments are no-ops as the RefCount isn't
+  // dictated by the class directly.
   RefCountedBase(const RefCountedBase &) {}
+  RefCountedBase(RefCountedBase &&) {}
+  RefCountedBase &operator=(const RefCountedBase &) { return *this; }
+  RefCountedBase &operator=(RefCountedBase &&) { return *this; }
----------------
dexonsmith wrote:
> dexonsmith wrote:
> > njames93 wrote:
> > > njames93 wrote:
> > > > dexonsmith wrote:
> > > > > dblaikie wrote:
> > > > > > I can't quite understand this comment - perhaps you could try rephrasing it?
> > > > > I'm not quite following why you needed to add these special members; it seems like just the destructor would be enough for the assertion; but if you do need them, can/should they be `= default`?
> > > > They can't be defaulted as we don't want to copy the RefCount.
> > > I understand it in my head, just can't think of the best way to write it down.
> > Maybe something like this would work:
> > ```
> > /// Do not copy or move RefCount when constructing or assigning from
> > /// a derived type. These operations don't imply anything about the
> > /// number of IntrusiveRefCntPtr instances.
> > ```
> > WDYT?
> Ah, I get it, thanks for explaining.
Do we need them at all, though?

The code prior to this patch has a copy ctor that "does the right thing" by producing a ref count of 0 for the new copy (same as a newly constructed object). No move operations will be provided - nor probably should there be any, the copy semantics are cheap/correct & not sure there's a more optimized implementation for move.

The copy assignment operaotr currently is probably broken (the implicit copy assignment is deprecated in the presence of a user-declared copy ctor - so we could probably delete that rather than adding it if it's not used (& at least, currently if it is used it'd be pretty broken).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D92480/new/

https://reviews.llvm.org/D92480