[clang-tidy] Support concepts in `bugprone-forwarding-reference-overload`

[Izaron]

Summary

Ignore constrained perfect forwarding constructors.

Fixes: #58230

[Izaron]

Fixes https://github.com/llvm/llvm-project/issues/58230

[Eugene.Zelenko]

clang-tools-extra/docs/clang-tidy/checks/bugprone/forwarding-reference-overload.rst

54

Please follow 80 characters limit.

[Izaron]

Follow 80 characters limit. Thanks to @Eugene.Zelenko!

[Izaron]

clang-tools-extra/docs/clang-tidy/checks/bugprone/forwarding-reference-overload.rst

54

Thanks! I ran git clang-format HEAD~1 before commiting, but it didn't modify this file. Seems like it doesn't see .rst files.

[Eugene.Zelenko]

clang-tools-extra/docs/clang-tidy/checks/bugprone/forwarding-reference-overload.rst

54

If I my memory is not failing me, @MyDeveloperDay once tried to introduce documentation linter, but I don't think that it reached production.

[PiotrZSL]

May require rebase, but looks fine.
Release notes entry should be added.

[PiotrZSL]

rebase, add release notes, move tests to separate file

clang-tools-extra/clang-tidy/bugprone/ForwardingReferenceOverloadCheck.cpp

AST_MATCHER(QualType, isEnableIf) {
   }
   return false;
 }
 AST_MATCHER_P(TemplateTypeParmDecl, hasDefaultArgument,
               clang::ast_matchers::internal::Matcher<QualType>, TypeMatcher) {
   return Node.hasDefaultArgument() &&
          TypeMatcher.matches(Node.getDefaultArgument(), Finder, Builder);
 }
+AST_MATCHER(TemplateDecl, hasAssociatedConstraints) {
+  return Node.hasAssociatedConstraints();
+}
 } // namespace
 
 void ForwardingReferenceOverloadCheck::registerMatchers(MatchFinder *Finder) {
   auto ForwardingRefParm =
       parmVarDecl(
           hasType(qualType(rValueReferenceType(),
                            references(templateTypeParmType(hasDeclaration(
                                templateTypeParmDecl().bind("type-parm-decl")))),
                            unless(references(isConstQualified())))))
           .bind("parm-var");
 
   DeclarationMatcher FindOverload =
       cxxConstructorDecl(
           hasParameter(0, ForwardingRefParm),
           unless(hasAnyParameter(
               // No warning: enable_if as constructor parameter.
               parmVarDecl(hasType(isEnableIf())))),
           unless(hasParent(functionTemplateDecl(anyOf(
+              // No warning: has associated constraints (like requires
+              // expression).
+              hasAssociatedConstraints(),
               // No warning: enable_if as type parameter.
               has(templateTypeParmDecl(hasDefaultArgument(isEnableIf()))),
               // No warning: enable_if as non-type template parameter.
               has(nonTypeTemplateParmDecl(
                   hasType(isEnableIf()),
                   anyOf(hasDescendant(cxxBoolLiteral()),
                         hasDescendant(cxxNullPtrLiteralExpr()),
                         hasDescendant(integerLiteral())))))))))

clang-tools-extra/docs/clang-tidy/checks/bugprone/forwarding-reference-overload.rst

public:
       template<typename T, typename X = enable_if_t<is_special<T>, void>>
       explicit Person(T&& n) {}
 
       // C4: variadic perfect forwarding ctor guarded with enable_if
       template<typename... A,
         enable_if_t<is_constructible_v<tuple<string, int>, A&&...>, int> = 0>
       explicit Person(A&&... a) {}
 
+      // C5: perfect forwarding ctor guarded with requires expression
+      template<typename T>
+      requires requires { is_special<T>; }
+      explicit Person(T&& n) {}
+
+      // C6: perfect forwarding ctor guarded with concept requirement
+      template<Special T>
+      explicit Person(T&& n) {}
+
       // (possibly compiler generated) copy ctor
       Person(const Person& rhs);
     };
 
 The check warns for constructors C1 and C2, because those can hide copy and move
 constructors. We suppress warnings if the copy and the move constructors are both
 disabled (deleted or private), because there is nothing the perfect forwarding
 constructor could hide in this case. We also suppress warnings for constructors
-like C3 and C4 that are guarded with an ``enable_if``, assuming the programmer was
+like C3-C6 that are guarded with an ``enable_if`` or a concept, assuming the programmer was
 aware of the possible hiding.
 
 Background
 ----------
 
 For deciding whether a constructor is guarded with enable_if, we consider the
 types of the constructor parameters, the default values of template type parameters
 and the types of non-type template parameters with a default literal value. If any
 part of these types is ``std::enable_if`` or ``std::enable_if_t``, we assume the
 constructor is guarded.
 

clang-tools-extra/test/clang-tidy/checkers/bugprone/forwarding-reference-overload.cpp

-// RUN: %check_clang_tidy %s bugprone-forwarding-reference-overload %t
+// RUN: %check_clang_tidy -std=c++20 %s bugprone-forwarding-reference-overload %t
 
 namespace std {
 template <bool B, class T = void> struct enable_if { typedef T type; };
 
 template <class T> struct enable_if<true, T> { typedef T type; };
 
 template <bool B, class T = void>
 using enable_if_t = typename enable_if<B, T>::type;

 class Test10 {
 public:
   enum E {};
   E e;
 
   Test10(T &&Item, E e)
       : e(e){}
 };
+
+class Test11 {
+public:
+  // Guarded with requires expression.
+  template <typename T>
+  requires requires { just_true<T>; }
+  Test11(T &&n);
+};
+
+template<typename T>
+concept JustTrueConcept = requires { just_true<T>; };
+
+class Test12 {
+public:
+  // Guarded with concept requirement.
+  template <JustTrueConcept T> Test12(T &&n);
+};