[PATCH] D16376: clang-tidy check: User-defined copy without assignment

[Alexander Kornienko via cfe-commits]

alexfh added inline comments.

================
Comment at: clang-tidy/misc/UserDefinedCopyWithoutAssignmentCheck.cpp:32
@@ +31,3 @@
+
+  if (MatchedDecl->isImplicit())
+    return;
----------------
This check should be done in the matcher.

================
Comment at: clang-tidy/misc/UserDefinedCopyWithoutAssignmentCheck.cpp:49
@@ +48,3 @@
+  llvm::raw_string_ostream Insertion(S);
+  Insertion << "\n" << ClassName << "& operator = (const " << ClassName << "&) = delete;";
+
----------------
aaron.ballman wrote:
> I think we usually prefer `operator=` to `operator =`, but am not certain.
+1 for `operator=`

Also, I'd use `(llvm::Twine("\n") + ClassName + ...).str()` instead of the stream.

================
Comment at: clang-tidy/misc/UserDefinedCopyWithoutAssignmentCheck.cpp:51
@@ +50,3 @@
+
+  Diag << FixItHint::CreateInsertion(CCtorEnd, Insertion.str());
+}
----------------
aaron.ballman wrote:
> We probably do not want to generate this fixit unless we are compiling for at least C++11. We should have a test for C++98.
Just insert this at the start of `registerMatchers`:

  if (!getLangOpts().CPlusPlus11)
    return;

================
Comment at: docs/clang-tidy/checks/misc-user-defined-copy-without-assignment.rst:6
@@ +5,3 @@
+
+MSVC 2015 will generate an assignment operator even if the user defines a copy constructor.
+This check finds classes with a user-defined (including deleted)
----------------
Is this problem only relevant to MSVC 2015? Is MSVC's behavior standard-compliant in this case?


Repository:
  rL LLVM

http://reviews.llvm.org/D16376