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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
