[cfe-users] How to check whether a type is_copy_assignable?

[Weston Carvalho via cfe-users]

HI,

I'm trying to write a tool that uses the AST to look at all the class
declarations in our codebase and get some metrics on our use of special
member functions. (How many classes are copyable, how many have
ctors without the corresponding assignment operator, etc.) I'm running into
some problems with implicitly declared special members. For example:

class UserDefCopy {
 public:
  UserDefCopy(const UserDefCopy&) {}
  UserDefCopy& operator=(const UserDefCopy&) { return *this; }
};
class ContainsUserDefCopy {
 private:
  UserDefCopy x_;
};

UserDefCopy has a CXXConstructorDecl for its copy constructor and a
CXXMethodDecl for the copy-assign operator, so I can use the methods on the
decls to get the info I need (isDeleted, isExplicitlyDefaulted, getAccess,
etc.) However, ContainsUserDefCopy's copy-assign operator is implicit, so
there's no decl for it. Since there's no decl, I can't differentiate
between a class with an implicitly defaulted copy-assign and one with an
implicitly deleted copy-assign. ContainsUserDefCopy does have a declaration
for its copy constructor, but AFAICT from looking at
clang::Sema::AddImplicitlyDeclaredMembersToClass
<https://clang.llvm.org/doxygen/classclang_1_1Sema.html#a2ddba48d645ed86f2f4d11b6e7a9010a>,
that's because special members with the needs_overload_resolution tag are
eagerly generated while others are deferred. I don't understand why the
ctor has the tag while the assign operator doesn't, though.

The questions I have are:

   1. What makes a method needs_overload_resolution? The docs in
   CXXRecordDecl just say that it "[determines] whether we need to eagerly
   declare a defaulted [member] for this class."
   2. Is there a different way I should query the AST so that I see any
   decls that were deferred during the Sema step? Or some other way to get
   this information? Trying to use an implicitly deleted copy assignment
   operator is a compiler error, so that information is obviously available
   *somewhere*.

Thanks,
Weston
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-users/attachments/20200206/d8466da1/attachment.html>