[clang-format] Improve clang-formats handling of concepts

[MyDeveloperDay]

Summary

This is a starting point to improve the handling of concepts in clang-format. There is currently no real formatting of concepts and this can lead to some odd formatting, e.g.

requires(R range) {
  typename Iterator_type<R>;
  { begin(range) }
  ->Iterator_type<R>;
  { end(range) }
  ->Iterator_type<R>;
  requires Input_iterator<Iterator_type<R>>();
};

template <typename T> concept Large = sizeof(T) > 10;

template <typename T, typename U> concept FooableWith = requires(T t, U u) {
  typename T::foo_type;
  { t.foo(u) }
  ->typename T::foo_type;
  t++;
};

The revision starts by resolving the additional newline added before the implicit conversion constraint and ensures that the concept keyword is always on the line below template<>

template <typename T>
concept bool EqualityComparable = requires(T a, T b) {
  { a == b } -> bool;
};

Additional Options include the following to allow a 1 level indentation of the requires clauses (as seems to be popular in a couple of sources, online reference and conference slides about concepts)

• IndentRequires (indent the "requires keyword after template")

e.g.

template <class I, class S>
   requires Sentinel<S, I>()
constexpr void advance(I &i, S bound) noexcept(noexcept(++i != bound)) {
  while (i != bound) {
    ++i;
  }
}

[MyDeveloperDay]

Add additional parsing of concept and require keywords to allow formatting

Include some more of @saar.raz examples in the tests

[MyDeveloperDay]

clang/lib/Format/TokenAnnotator.cpp

1923

This change it to resolve the missing gap between && and Concept2, clang-format incorrectly labels the && as TT_PointerOrReference

template <class I> void f(I i) requires Concept1<I> &&Concept2<i> {
  // ...
}

vs

template <class I> void f(I i) requires Concept1<I> && Concept2<i> {
  // ...
}

[MyDeveloperDay]

Add support for IndentRequires add additional tests for interaction with SpaceBeforeParens

[MyDeveloperDay]

Introduce the concept of TT_ConstraintJuncitons for both && and || (Conjunctions and Disjunctions) as these were confusing the layout as often they are treated as TT_BinaryOperator and or TT_PointerOrReference

This allow more specific concepts base rules and keeps the code separate from other TT_BinaryOperator rules

[miscco]

Awesome, Thank you very much, I dragged my feet on starting to implement something for real.

As a high level comment I think we need to handle requires expressions to get this correct, as requires requires would otherwise to bad things.

From my early brainstorming i got the following options I thought useful. This is in no ways a request for you to implement them, but I would want to get them out here in case they are usefull

/// Different styles for merging short requires-clauses with the template
  /// decalaration
  enum ShortRequiresClauseStyle {
    /// Never merge requires clauses into a single line.
    /// \code
    ///   template <class T>
    ///   requires someConstraint<T>
    ///   T foo();
    /// \endcode
    SRCS_Never,
    /// Only merge requires clauses with a single constraint.
    /// \code
    ///   template <class T> requires someConstraint<T>
    ///   T foo();
    ///
    ///   template <class T>
    ///   requires someConstraint<T> && otherConstraint<T>
    ///   T bar();
    /// \endcode
    SRCS_Single,
    /// Merge requires clauses if they are short
    /// \code
    ///   template <class T> requires short<T> && shorter<T>
    ///   T foo();
    ///
    ///   template <class T>
    ///   requires someReallyLongElaborateConstraintThatIsReallyLong<T>
    ///   T bar();
    ///
    ///   template <class T>
    ///   requires someLongConstraint<T> && otherLongConstraint<T>
    ///   T baz();
    /// \endcode
    SRCS_Short,
    /// Always try to merge the requires clause with the template declaration
    /// \code
    ///   template <class T> requires someLongConstraint<T> &&
    ///                               otherLongConstraint<T>
    ///   T foo();
    /// \endcode
    SRCS_Always,
  };

  /// Dependent on the value, requires-clauses can be put on the same line
  /// as the template declaration.
  ShortRequiresClauseStyle AllowShortRequiresClause;

  /// Dependent on the value, requires-expressions can be a single line
  /// Always try to merge the requires clause with the template declaration
  /// \code
  ///   template <class T> requires someLongConstraint<T> &&
  ///                               requires { T{}; }
  ///   T foo();
  /// \endcode
  bool AllowShortRequiresExpression;

   /// Dependent on the value break before or after constraint expressions.
  enum ConstraintExpressionBreakingStyle {
    /// Break after constraint expressions but multiple may be on single line
    /// \code
    ///   template <class T> requires someLongConstraint<T> &&
    ///                               otherLongConstraint<T>
    ///   T foo();
    ///
    ///   template <class T> requires short<T> && shorter<T> &&
    ///                               otherLongConstraint<T>
    ///   T bar();
    /// \endcode
    CEBS_After,
    /// Break after constraint expressions.
    /// \code
    ///   template <class T> requires short<T> &&
    ///                               shorter<T> &&
    ///                               otherLongConstraint<T>
    ///   T bar();
    /// \endcode
    CEBS_AfterSingleExpression,
    /// Break before constraint expressions but multiple may be on single line
    /// \code
    ///   template <class T> requires someLongConstraint<T> &&
    ///                               otherLongConstraint<T>
    ///   T foo();
    ///
    ///   template <class T> requires short<T> && shorter<T>
    ///                            && otherLongConstraint<T>
    ///   T bar();
    /// \endcode
    CEBS_Before,
    /// Break before constraint expressions.
    /// \code
    ///   template <class T> requires short<T>
    ///                            && shorter<T>
    ///                            && otherLongConstraint<T>
    ///   T foo();
    /// \endcode
    CEBS_BeforeSingleExpression,
  };

  /// The constraint expressions style to use.
  ConstraintExpressionBreakingStyle BreakBeforeConstraintExpression;

  /// Dependent on the value wrap before or after requires expressions.
  enum BraceWrappingRequiresExpressionStyle {
    /// Do not wrap braces of requires expressions
    /// \code
    ///   template <class T> requires requires {  T{};
    ///                                           T(int); }
    ///   T foo();
    /// \endcode
    BWARES_NoWrap,
    /// Wrap after requires expressions.
    /// \code
    ///   template <class T> requires requires { T{};
    ///                                          T(int);
    ///                                        }
    ///   T foo();
    /// \endcode
    BWARES_WrapAfter,
    /// Wrap after requires expressions.
    /// \code
    ///   template <class T> requires requires
    ///                               { T{};
    ///                                 T(int); }
    ///   T foo();
    /// \endcode
    BWARES_WrapBefore,
    /// Wrap after requires expressions with a new line.
    /// \code
    ///   template <class T> requires requires
    ///                               {
    ///                                 T{};
    ///                                 T(int); }
    ///   T foo();
    /// \endcode
    BWARES_WrapBeforeWithNewline,
    /// Wrap before requires expressions.
    /// \code
    ///   template <class T> requires requires
    ///                               { T{};
    ///                                 T(int);
    ///                               }
    ///   T foo();
    /// \endcode
    BWARES_WrapBoth,
    /// Wrap before requires expressions.
    /// \code
    ///   template <class T> requires requires
    ///                               {
    ///                                 T{};
    ///                                 T(int);
    ///                               }
    ///   T foo();
    /// \endcode
    BWARES_WrapBothWithNewline,
  };

  /// The requires expressions style to use.
  BraceWrappingRequiresExpressionStyle BraceWrappingRequiresExpression;

My problem was that I had no idea how to properly tokenize the logical-or-constraint-expression. I have pushed my super clumsy WIP stuff here:
https://github.com/miscco/llvm-project/pull/new/clang_format_concepts

If I can help you in any way please tell me

clang/lib/Format/TokenAnnotator.cpp

1566–1570

Should that really be tok::arrow and not tok::kw_requires?

3484

I think we should have an option to allow short requires clauses on the same line similar to allow short functions

clang/lib/Format/UnwrappedLineParser.cpp

2286

I believe we should separate between constraint expressions aka: tempalte< > requires Concept1 && Concept2 and requires expressions aka requires { ... }

The two are quite different. That said the handling of requires expressions should be "simple" as we only need to find the matching "}".

As an upside this would also handle the famous requires requires

[MyDeveloperDay]

clang/lib/Format/TokenAnnotator.cpp

1566–1570

This is to prevent the breaking between } and -> in the following (which could be some way from the requires

{ t.foo(u) } -> typename T::foo_type;

3484

Actually at present it will pull short requires onto a new line, this particular line is about keeping concept on a new line (most examplesI've seen are like this..i.e.

template<typename T>
concept...

rather than

template<typename T> concept...

For me the natural thing here is to enforce a newline and then relax that later if we think it needs it, but I'm wary of adding too many options upfront.

This is virgin territory as most style guides out there don't specify anything for concepts yet, to be honest i'd prefer to establish an LLVM style and wait for the other style guides to catch up. (I know we will revisit this later), just want to keep the initial commit small. (incremental development is encouraged in LLVM) and multiple options will be a huge commit that never gets passed.

clang/lib/Format/UnwrappedLineParser.cpp

2286

This is effectively the if at line 2305 seeing "requires {" or requires(Foo t) {" sets off down the parseBlock path which can itself include requires.

If you do have an example you think would break this please feel free to add that in a comment and I'll add it to the unit tests and rework accordingly.

My exposure to concepts is still pretty new, I'm not even sure I've covered all the places it can be used, but I wanted to start because at present I see alot of the MS STL(@STL_MSFT ) covered with // clang-format off around the concepts.

[miscco]

clang/lib/Format/TokenAnnotator.cpp

3494

I think that your change should actually come in here where we determine what to do after a ClosesTemplateDeclaration

With an potential new option AlwaysBreakConceptDeclarations that should probably default to AlwaysBreakTemplateDeclarations this would read

if (Right.Previous->ClosesTemplateDeclaration &&
    Right.Previous->MatchingParen &&
    Right.Previous->MatchingParen->NestingLevel == 0) { 
    if (Right.is(tok::kw_requires)) {
      switch(Style.AllowShortRequiresClause) {
        case FormatStyle::SRCS_Never: 
          return true;
        case FormatStyle::SRCS_Always: 
          return false;
        case FormatStyle::SRCS_Single:
          // TODO: Determine whether there is a single constraint 
          return true;
        case FormatStyle::SRCS_Short: 
          // TODO: Determine whether the constraint clause is short enough
          return true;
      } 
    } else if (Right.is(tok::kw_concept)) {
      return Style.AlwaysBreakConceptDeclarations == FormatStyle::BTCS_Yes);
    } else {
      return Style.AlwaysBreakTemplateDeclarations == FormatStyle::BTDS_Yes);
    }
}

[MyDeveloperDay]

clang/lib/Format/TokenAnnotator.cpp

3494

yes this is a better place

[MyDeveloperDay]

Move break before concept into correct clause
Add requires requires test

[miscco]

You are missing to check the boolean in CHECK_PARSE_BOOL in FormatTest.cpp

clang/lib/Format/TokenAnnotator.cpp

1566–1570

I believe this should carry some state that we are inside of an requires-expression.

3484

Personally I agree that this is the natural style, at the same time there are configurations that allow short template declarations on a single line, which I believe would be similarly welcome.

That said I agree adding this later is fine

clang/lib/Format/UnwrappedLineParser.cpp

2286

Yes that was also the reason I tried it out because I often added those // clang-format off snippets once too often

[miscco]

clang/lib/Format/UnwrappedLineParser.cpp

2283

I believe this should be parseConstraintExpression because that is the term of art in the standard.

The requires expression is what is the requieres { } and that can be part of an constraint expression

[miscco]

clang/lib/Format/UnwrappedLineParser.cpp

2314

I guess you could use parseBracedList(/*ContinueOnSemicolons=*/false, /*IsEnum=*/false,/*ClosingBraceKind=*/tok::greater); here?

[miscco]

clang/lib/Format/UnwrappedLineParser.cpp

2314

To be more specific, I am concerned what happens if you have multiple template arguments where a linebreak should occur. Is this still happening here?

template <typename someLongTypename1, typename someLongTypename2>
concept someVeryLongConceptName = someVeryLongConstraintName1<someLongTypename1 && someLongTypename2>;

clang/unittests/Format/FormatTest.cpp

16319

I think concept bool should just be concept occurs below

[MyDeveloperDay]

clang/lib/Format/TokenAnnotator.cpp

1566–1570

I'm not sure how possible that is as its dealt with in terms of normal parseBlock() handling so there might not be a possiblity to label the -> (which is actually what I'm just doing here) the other rules regarding TT_TrailingReturnArrow will ensure its doesn't get broken and there is spaces around it.

[MyDeveloperDay]

Add new AlwaysBreakBeforeConceptDeclarations

Better handling of requires expressions vs constraint expression

add more concept tests from the twitter-sphere

[MyDeveloperDay]

clang/lib/Format/UnwrappedLineParser.cpp

2283

I'm making some of these changes, the problem is with the form

concept id = Foo<T> && Bar<T>

in this case the

Foo<T> && Bar<T>

will be processed by the parseStructualElement() and this gets confused with the && being a TT_PointerOrRefernce and not a TT_BinaryOperator and that throws everything out.

I think parseStructualElement() is thinking Foo<T> && is part of

foo(Foo<T> &&abc);

and not

Foo<T> && abc<T>

We need to know we are in a concept expression

2314

This is formatted as

template <typename someLongTypename1, typename someLongTypename2>
concept someVeryLongConceptName =
    someVeryLongConstraintName1<someLongTypename1 && someLongTypename2>;

[miscco]

Question: Should I add my wip work as a child revision or what would you suggest

[MyDeveloperDay]

In D79773#2046565, @miscco wrote:

Question: Should I add my wip work as a child revision or what would you suggest

Certainly your revision on github was useful for me to take a look at, but to be honest this change is getting large and I don't like landing such a large change in one go but rather make small incremental improvements (I believe this is the LLVM way)

Feel free to create a revision (and reference it here). Once we land some form of initial implementation I feel we can start making improvement as we detect corner cases or adding new options (and that might be more easily spread between developers)

To be honest I would rather start getting bugs from external users than clang-format being the butt of peoples complaints https://twitter.com/the_moisrex/status/1262982971973423105

[miscco]

It seems the spacing of the binary operator is not yet stable. This test is breaking for me:

verifyFormat("template <typename T>\nconcept someConcept = Constraint1<T> && Constraint2<T>;");

[MyDeveloperDay]

In D79773#2046833, @miscco wrote:

It seems the spacing of the binary operator is not yet stable. This test is breaking for me:

verifyFormat("template <typename T>\nconcept someConcept = Constraint1<T> && Constraint2<T>;");

Hmm... are you upto date

$ ./FormatTests.exe --gtest_filter=*Concept*
Note: Google Test filter = *Concept*
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from FormatTest
[ RUN      ] FormatTest.ConceptsAndRequires
[       OK ] FormatTest.ConceptsAndRequires (642 ms)
[----------] 1 test from FormatTest (645 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test case ran. (650 ms total)
[  PASSED  ] 1 test.

[MyDeveloperDay]

Rebase

[miscco]

clang/lib/Format/UnwrappedLineParser.cpp

2290

Line->Level is an unsigned int so this gives me a warning. I guess it should be unsigned int OriginalLevel same below

[MyDeveloperDay]

switch function to unsigned

[JohelEGP]

BreakBeforeBraces: Allman isn't respected.

template <class D, class U, class Rep2>
friend constexpr auto
operator*(const size2d& l, const units::quantity<D, U, Rep2>& r) noexcept(
    noexcept(l.w* r)) requires(requires { l.w* r; }) //
{
    return size2d<decltype(l.w() * r)>{l.w * r, l.h * r};
}

When a trailing requires-clause is right before the function body, its opening brace should go on its own line, as dictated by my config file.

[curdeius]

clang/include/clang/Format/Format.h

522

It would be nice to have an example here in the doc.

clang/unittests/Format/FormatTest.cpp

13374

Format: leading whitespace. Should it be in the same "group" as AlignConsecutiveMacros?

16482

Isn't it a strange indentation?

[JohelEGP]

constexpr plane(const plane& other) noexcept(
    (detail::default_allocator_is_nothrow &&
     std::is_nothrow_copy_constructible_v<T>)) requires(std::copyable<T>)
  : plane{to1d(other), other.sz.w}
{
}

Without the parentheses in trailing requires-clauses, all code following the constructor initializer list is further indented.

[MyDeveloperDay]

clang/unittests/Format/FormatTest.cpp

13374

I might be misunderstanding your comment, but the list should alphabetic but now I realize it should be after the Allows

16482

there is no newline on the line above, but I clang-format the tests so it wraps it, I know visually its confusing

[MyDeveloperDay]

In D79773#2124231, @JohelEGP wrote:

constexpr plane(const plane& other) noexcept(
    (detail::default_allocator_is_nothrow &&
     std::is_nothrow_copy_constructible_v<T>)) requires(std::copyable<T>)
  : plane{to1d(other), other.sz.w}
{
}

Without the parentheses in trailing requires-clauses, all code following the constructor initializer list is further indented.

Just so I'm clear for this and your Allman coment would you show me what you are seeing and what you expect to see? just so I understand.

[JohelEGP]

In D79773#2125040, @MyDeveloperDay wrote:

Just so I'm clear for this and your Allman coment would you show me what you are seeing and what you expect to see? just so I understand.

Sure, thank you.

This is what I have, as shown above. Actually fixed to show surrounding context, which is relevant to formatting. Note the // comment:

namespace jge
{
template <std::regular Rep>
struct [[nodiscard]] size2d
{
    template <class D, class U, class Rep2>
    friend constexpr auto
    operator*(const size2d& l, const units::quantity<D, U, Rep2>& r) noexcept(
        noexcept(l.w* r)) requires(requires { l.w* r; }) //
    {
        return size2d<decltype(l.w() * r)>{l.w * r, l.h * r};
    }
};

} // namespace jge

I added // to make the formatting look like what I want. If I remove it, this is what I get:

namespace jge
{
template <std::regular Rep>
struct [[nodiscard]] size2d
{
    template <class D, class U, class Rep2>
    friend constexpr auto
    operator*(const size2d& l, const units::quantity<D, U, Rep2>& r) noexcept(
        noexcept(l.w* r)) requires(requires { l.w* r; }) {
        return size2d<decltype(l.w() * r)>{l.w * r, l.h * r};
    }
};

} // namespace jge

So this is what I want, without the // comment:

namespace jge
{
template <std::regular Rep>
struct [[nodiscard]] size2d
{
    template <class D, class U, class Rep2>
    friend constexpr auto
    operator*(const size2d& l, const units::quantity<D, U, Rep2>& r) noexcept(
        noexcept(l.w* r)) requires(requires { l.w* r; }) 
    {
        return size2d<decltype(l.w() * r)>{l.w * r, l.h * r};
    }
};

} // namespace jge

For the constructor initializer list, this is what I have. Note the parentheses in the first requires-clause:

namespace jge
{
template <class T>
class [[nodiscard]] plane
{
    constexpr plane(const plane& other) noexcept(
        (detail::default_allocator_is_nothrow &&
         std::is_nothrow_copy_constructible_v<T>)) requires(std::copyable<T>)
      : plane{to1d(other), other.sz.w}
    {
    }

    constexpr plane& operator=(const plane& other) noexcept(
        (std::is_nothrow_copy_constructible_v<plane> &&
         std::is_nothrow_copy_assignable_v<T>)) requires std::copyable<T> //
    {
        assign(to1d(other), other.sz.w);
        return *this;
    }
};

} // namespace jge

This is what I get without the parentheses. Note that all code after the constructor initializer list is further indented:

namespace jge
{
template <class T>
class [[nodiscard]] plane
{
    constexpr plane(const plane& other) noexcept(
        (detail::default_allocator_is_nothrow &&
         std::is_nothrow_copy_constructible_v<T>)) requires std::copyable<T>
      : plane{to1d(other), other.sz.w}
      {
      }

      constexpr plane& operator=(const plane& other) noexcept(
          (std::is_nothrow_copy_constructible_v<plane> &&
           std::is_nothrow_copy_assignable_v<T>)) requires std::copyable<T> //
      {
          assign(to1d(other), other.sz.w);
          return *this;
      }
};

} // namespace jge

So this is what I want. Without extra parentheses, nor extra indentation:

namespace jge
{
template <class T>
class [[nodiscard]] plane
{
    constexpr plane(const plane& other) noexcept(
        (detail::default_allocator_is_nothrow &&
         std::is_nothrow_copy_constructible_v<T>)) requires std::copyable<T>
      : plane{to1d(other), other.sz.w}
    {
    }

    constexpr plane& operator=(const plane& other) noexcept(
        (std::is_nothrow_copy_constructible_v<plane> &&
         std::is_nothrow_copy_assignable_v<T>)) requires std::copyable<T> //
    {
        assign(to1d(other), other.sz.w);
        return *this;
    }
};

} // namespace jge

All with the config file linked above.

[MyDeveloperDay]

Thank you I see now... super subtle but I'll take a look.

[JohelEGP]

Using parameter packs within non-parenthesized requires-clauses results in weird formatting:

template <std::semiregular F, std::semiregular... Args>
    requires std::invocable < F, std::invoke_result_t<Args>
... > struct constant;

vs

template <std::semiregular F, std::semiregular... Args>
    requires(std::invocable<F, std::invoke_result_t<Args>...>)
struct constant;

[MyDeveloperDay]

Still a work in progress but covers I think the case @JohelEGP found.

[curdeius]

clang/unittests/Format/FormatTest.cpp

13374

I just wanted to point out that when you don't put a blank line after CHECK_PARSE_BOOL, then the next one gets indented. And yes, the order isn't ok. BTW, us "Always" in the name necessary? Cf. other "Break" options.

16482

O, ok, thanks for the explanation. It's indeed confusing in the review.

[MyDeveloperDay]

clang/unittests/Format/FormatTest.cpp

13374

@curdeius I didn't get to make changes to match your previous review comments yet, but I 100% agree with you why did I put Always here!

I WILL remove that as I can see further down the road if this got changed to an enumeration it would be

AlwaysBreakBeforeConceptDeclarations = Always
AlwaysBreakBeforeConceptDeclarations = Sometimes
AlwaysBreakBeforeConceptDeclarations = Never

Which would be very confusing...

I'll address those concerns next

[MyDeveloperDay]

Addressed review comments
Added one or two more tests

NOTE: renamed the option from AlwaysBreakBeforeConceptDeclarations -> BreakBeforeConceptDeclarations

[JohelEGP]

Thank you. Everything I reported works fine now.

I have two more cases for now. First are your examples in the OP.
You have

template <typename T>
concept bool EqualityComparable = requires(T a, T b) {
  { a == b } -> bool;
};

But this is what I get:

template <typename T>
concept bool EqualityComparable = requires(T a, T b)
{
    {
        a == b
        } -> bool;
};

Perhaps it's because I compiled against commit 71d88cebfb42c8c5ac2d54b42afdcca956e55660 (Fri Jul 3 13:46:41 2020 -0400).
Next:

template <std::semiregular F, std::semiregular... Args>
    requires std::invocable<F, std::invoke_result_t<Args>...>
struct [[nodiscard]] constant : std::bool_constant < requires
{
    typename _require_constant_<(std::invoke(F{}, Args{}()...), 0)>;
} > {};

There's spaces around the template brackets. The lack of indentation is also odd, considering that in this context things are indented.

[JohelEGP]

Another weird formatting when direct-initializing a variable with a non-parenthesized requires-expression:

constexpr void test_width()
{
    bool invalid_rep{!requires {typename jge::width<T>;
}
}
;
}

vs

constexpr void test_width()
{
    bool invalid_rep{!(requires { typename jge::width<T>; })};
    bool invalid_rep = !(requires { typename jge::width<T>; });
    bool invalid_rep = !requires
    {
        typename jge::width<T>;
    };
}

[MyDeveloperDay]

Thank you @JohelEGP please keep them coming, I'll try and update the patch as soon as I have some fixes, I kind of feel like we are addressing what would have just been downstream bugs anyway. (some are quite bizarre!) so lets squish as many of them as we can before we land this.

My assumption is you are giving me valid c++ code, if so that is great I'll try and address them, but your examples are probably beyond my own concepts knowledge. (This is actually why I started to add this to clang-format, I wanted a way to learn about concepts)

[JohelEGP]

Yes, it's valid C++ (is my hope). It's from WIP code, which I made available to show you: https://github.com/johelegp/jge.

Here it is building, running and passing the tests: https://travis-ci.com/github/johelegp/jge/jobs/358137355#L559.

Here are links to the above linked snippets:

• Now looking good:
  • https://github.com/johelegp/jge/blob/master/include/jge/cartesian.hpp#L84-L90
  • https://github.com/johelegp/jge/blob/master/include/jge/plane.hpp#L54-L59
  • https://github.com/johelegp/jge/blob/master/tests/jge/cartesian.cpp#L18-L20.
• Just reported:
  • Inheritance: https://github.com/johelegp/jge/blob/master/tests/jge/cartesian.cpp#L11-L21 (https://reviews.llvm.org/D79773#2131680)
  • Non list-initialization: https://github.com/johelegp/jge/blob/master/tests/jge/cartesian.cpp#L11-L16 (https://reviews.llvm.org/D79773#2132086)
  • For the EqualityComparable case (https://reviews.llvm.org/D79773#2131680), I use this macro: https://github.com/johelegp/jge/blob/master/include/jge/detail/quantity_wrappers.hpp#L4-L5. Example: https://github.com/johelegp/jge/blob/master/include/jge/detail/quantity_wrappers.hpp#L59. I also used it before the previous fixes besides // comments.

[MyDeveloperDay]

https://reviews.llvm.org/D79773#2131680 has something to do with your .clang-format file, the base LLVM style seems fine.

template <typename T>
concept bool EqualityComparable = requires(T a, T b) {
    { a == b } -> bool;
};

vs

template <typename T>
concept bool EqualityComparable = requires(T a, T b)
{
    {
        a == b
        } -> bool;
};

From what I can tell its because of the "BreakBeforeBraces: Allman or GNU" styles.

I'm wondering what an Allman version should look like?

template <typename T>
concept bool EqualityComparable = requires(T a, T b)
{
    {
        a == b
     } -> bool;
};

[JohelEGP]

Ah, that makes sense. The very definition of Allman is to always break before braces. I suppose I'll need to use BreakBeforeBraces: Custom and BraceWrapping:. I did some testing and noticed that the weird format comes with any of these:

BreakBeforeBraces: Custom
BraceWrapping:
  AfterControlStatement: MultiLine

BreakBeforeBraces: Custom
BraceWrapping:
  AfterFunction: true

Since a compound requirement is neither a control statement nor a function, I suppose it might eventually need its own BraceWrapping nested configuration flag. For now, I'd prefer if they never break.

[MyDeveloperDay]

This issue is caused by the presence of the ; in the requires clause (0)>;) inside the template declaration

template <std::semiregular F, std::semiregular... Args>
    requires std::invocable<F, std::invoke_result_t<Args>...>
struct [[nodiscard]] constant : std::bool_constant < requires
{
    typename _require_constant_<(std::invoke(F{}, Args{}()...), 0)>;
} > {};

These below may not be legal C++ examples but show the same behaviour

struct constant : Foo < typename {
    Foo;
} > {};

struct constant : Foo<typename {Foo}> { };

This is actually failing in the handling of parsing the <> in (parseAngle() actually parseBrace() inside of that), it is not really concepts specific except it may be seen now because of the presence of the ;

The problem comes about I think because the line is broken by the ; during the parseBrace at some point the Next token is null, I assume that's because the lines are broken by the ; as such ultimately the < and > rather than being seen as TT_TemplateOpener and TT_TemplateCloser are seen as TT_BinaryOperators (by default when 'parseAngle' fails)

I'm not sure how I could solve this, I might need help from a higher power @klimek

[klimek]

clang/lib/Format/UnwrappedLineParser.cpp

631–636

I'd have expected this to be just in front of line 629 (if... tok::semi) - does that break something? Don't we want to munch the semi after this?

2314

This seems like a very detailed way to parse them; generally, we try to only parse rough structure here.

[JohelEGP]

I found another case. See how everything after the requires-clause is indented for constructors with just the constructor's name (it works otherwise, maybe because it looks like a function).

class [[nodiscard]] data_t
{
public:
    template <std::ranges::input_range R>
        requires std::same_as<std::ranges::range_value_t<R>, flippable_tile_id>
        /*explicit*/ data_t(R&& ids, const format_t f = encoding_t::csv)
          : format_t{f}, tile_ids_{ranges::to_vector(std::forward<R>(ids))}
        {
        }

        [[nodiscard]] bool operator==(const data_t&) const = default;
};

[JohelEGP]

In D79773#2141164, @MyDeveloperDay wrote:

This is actually failing in the handling of parsing the <> in (parseAngle() actually parseBrace() inside of that), it is not really concepts specific except it may be seen now because of the presence of the ;

I opened LLVM 47161 to defer this to upstream.

[JohelEGP]

Could you do a rebase? The patch no longer applies:

error: patch failed: clang/docs/ClangFormatStyleOptions.rst:2711
error: clang/docs/ClangFormatStyleOptions.rst: patch does not apply
error: patch failed: clang/docs/ReleaseNotes.rst:398
error: clang/docs/ReleaseNotes.rst: patch does not apply
error: patch failed: clang/lib/Format/FormatToken.h:470
error: clang/lib/Format/FormatToken.h: patch does not apply
error: patch failed: clang/lib/Format/TokenAnnotator.cpp:1337
error: clang/lib/Format/TokenAnnotator.cpp: patch does not apply

[MyDeveloperDay]

Rebase the patch

[curdeius]

@MyDeveloperDay, is there anything I can do to help you on that?

BTW, libc++ would like to use clang-format (more than it does currently) and having concepts support would be awesome as there are more and more concept-related patches coming in.
IMHO, even support for most common cases would be a great improvement.

[MyDeveloperDay]

I don't think it was far off, I just I agreed with @klimek in trying to address the many different cases that came up I started to feel that parseConstraintExpression was becoming fragile

Having said that I like to think because they are in concepts specific parse code I won't break too much (famous last words!), any if you've tried to format concept code with the current clang-format well good luck with that.

Perhaps something is better than nothing?

if you think it has merits, if it covers most cases ok, then I'd be happy to see it land and work on any refinements from there.

[curdeius]

It would be maybe possible to:

• address @klimek 's comment and do any other necessary cleanup
• create a bug ticket for what @JohelEGP found with ctors
• mark clang-format's support of concept as experimental?

This patch is getting big IMO and I really think that something is better than nothing in this case.
And at least we could parallelise the efforts on the remaining (edge) cases when this gets landed.
WDYT?

[MyDeveloperDay]

rebase before making any further changes

[MyDeveloperDay]

clang/lib/Format/UnwrappedLineParser.cpp

2314

So whilst I tend to agree, and I've tried to write this loop to be less and it just didn't seem to catch the cases that had already been given in the unit tests,

This ended up being a lot likes its own parseStructuralElement, I think the difference here is that I've written it as a series of if's rather than a switch statement.

I feel I'd be happier to push the patch through then address individual specific cases

[MyDeveloperDay]

Address the issue with still munching the semi
mark as experimental in the release notes

[MyDeveloperDay]

Having reviewed the current status I'm going to leave this patch with just minor changes from where its been for some time, if others feel it has merits in landing as experimental support I'd be happy with that. I would rather build from a base than try and keep rebuilding the same tower.

The concepts support in clang-format is currently poor, actually, it's downright destructive, I've tried to cover the basic concept usage and I'm happy to support this feature against individual bug report where I can.

[miscco]

As someone who has extensivly worked with conscepts I cannot stress how much this would improve my live

[MyDeveloperDay]

In D79773#2432088, @miscco wrote:

As someone who has extensively worked with concepts I cannot stress how much this would improve my live

and I'd like to think that this will help even in its current form, but it needs someone to accept it first before it can land,

This has been my problem with clang-format , I do try and give some of my time to keeping up with the new and outstanding reviews coming in, but my own progress on clang-format or the fixing of bugs has slowed up because of a lack of people to review, we just need a couple more people who are willing to come once or twice a week and just keep things rolling along. but someone has to "watch the watcher" too.

[mitchell-stellar]

I am in favor of landing this and iterating.

[curdeius]

LGTM.

[MyDeveloperDay]

@JohelEGP can you let me know if you plan to remove the "requested changes" you asked for back in July?

I cannot commit with the revision until that is removed

[JohelEGP]

I was a bit late, but thanks for everything!

[MyDeveloperDay]

In D79773#2434126, @JohelEGP wrote:

I was a bit late, but thanks for everything!

No problem, sorry not for waiting, but let the games begin.

P.S. I think I may have left a comment for you over in one of your bugs. not sure if you saw that

[JohelEGP]

Yes, here's my reply: https://bugs.llvm.org/show_bug.cgi?id=47161#c2.

clang/docs/ClangFormatStyleOptions.rst

.. code-block:: c++
        #if FOO
          #if BAR
            #include <foo>
          #endif
        #endif
 
 
 
+**IndentRequires** (``bool``)
+  Indent the requires clause in a template
+
+  .. code-block:: c++
+
+     true:
+     template <typename It>
+       requires Iterator<It>
+     void sort(It begin, It end) {
+       //....
+     }
+
+     false:
+     template <typename It>
+     requires Iterator<It>
+     void sort(It begin, It end) {
+       //....
+     }
+
 **IndentWidth** (``unsigned``)
   The number of columns to use for indentation.
 
   .. code-block:: c++
 
      IndentWidth: 3
 
      void f() {

clang/docs/ReleaseNotes.rst

.. code-block:: c++
         });
 
       false:
       connect([]() {
           foo();
           bar();
         });
 
+- Option ``IndentRequires`` has been added to indent the ``requires`` keyword
+  in templates.
+
+  Support in clang-format for concepts has been improved
+
 libclang
 --------
 
 - ...
 
 Static Analyzer
 ---------------
 

clang/include/clang/Format/Format.h

struct FormatStyle {
 
   /// The function definition return type breaking style to use.  This
   /// option is **deprecated** and is retained for backwards compatibility.
   DefinitionReturnTypeBreakingStyle AlwaysBreakAfterDefinitionReturnType;
 
   /// The function declaration return type breaking style to use.
   ReturnTypeBreakingStyle AlwaysBreakAfterReturnType;
 
   /// If ``true``, always break before multiline string literals.
   ///
   /// This flag is mean to make cases where there are multiple multiline strings
   /// in a file look more consistent. Thus, it will only take effect if wrapping
   /// the string at that point leads to it being indented
   /// ``ContinuationIndentWidth`` spaces from the start of the line.
   /// \code
   ///    true:                                  false:
   ///    aaaa =                         vs.     aaaa = "bbbb"
enum PPDirectiveIndentStyle {
     ///    #endif
     /// \endcode
     PPDIS_BeforeHash
   };
 
   /// The preprocessor directive indenting style to use.
   PPDirectiveIndentStyle IndentPPDirectives;
 
+  /// Indent the requires clause in a template
+  /// \code
+  ///    true:
+  ///    template <typename It>
+  ///      requires Iterator<It>
+  ///    void sort(It begin, It end) {
+  ///      //....
+  ///    }
+  ///
+  ///    false:
+  ///    template <typename It>
+  ///    requires Iterator<It>
+  ///    void sort(It begin, It end) {
+  ///      //....
+  ///    }
+  /// \endcode
+  bool IndentRequires;
+
   /// The number of columns to use for indentation.
   /// \code
   ///    IndentWidth: 3
   ///
   ///    void f() {
   ///       someFunction();
   ///       if (true, false) {
   ///          f();
enum SpaceBeforeParensOptions {
     ///    void f() {
     ///      if (true) {
     ///        f();
     ///      }
     ///    }
     /// \endcode
     SBPO_ControlStatements,
     /// Same as ``SBPO_ControlStatements`` except this option doesn't apply to
-    /// ForEach macros. This is useful in projects where ForEach macros are 
-    /// treated as function calls instead of control statements. 
+    /// ForEach macros. This is useful in projects where ForEach macros are
+    /// treated as function calls instead of control statements.
     /// \code
     ///    void f() {
     ///      Q_FOREACH(...) {
     ///        f();
     ///      }
     ///    }
     /// \endcode
     SBPO_ControlStatementsExceptForEachMacros,
return AccessModifierOffset == R.AccessModifierOffset &&
            IncludeStyle.IncludeIsMainRegex ==
                R.IncludeStyle.IncludeIsMainRegex &&
            IncludeStyle.IncludeIsMainSourceRegex ==
                R.IncludeStyle.IncludeIsMainSourceRegex &&
            IndentCaseLabels == R.IndentCaseLabels &&
            IndentCaseBlocks == R.IndentCaseBlocks &&
            IndentGotoLabels == R.IndentGotoLabels &&
            IndentPPDirectives == R.IndentPPDirectives &&
-           IndentWidth == R.IndentWidth && Language == R.Language &&
+           IndentRequires == R.IndentRequires && IndentWidth == R.IndentWidth &&
+           Language == R.Language &&
            IndentWrappedFunctionNames == R.IndentWrappedFunctionNames &&
            JavaImportGroups == R.JavaImportGroups &&
            JavaScriptQuotes == R.JavaScriptQuotes &&
            JavaScriptWrapImports == R.JavaScriptWrapImports &&
            KeepEmptyLinesAtTheStartOfBlocks ==
                R.KeepEmptyLinesAtTheStartOfBlocks &&
            MacroBlockBegin == R.MacroBlockBegin &&
            MacroBlockEnd == R.MacroBlockEnd &&

clang/lib/Format/Format.cpp

static void mapping(IO &IO, FormatStyle &Style) {
     IO.mapOptional("IncludeCategories", Style.IncludeStyle.IncludeCategories);
     IO.mapOptional("IncludeIsMainRegex", Style.IncludeStyle.IncludeIsMainRegex);
     IO.mapOptional("IncludeIsMainSourceRegex",
                    Style.IncludeStyle.IncludeIsMainSourceRegex);
     IO.mapOptional("IndentCaseLabels", Style.IndentCaseLabels);
     IO.mapOptional("IndentCaseBlocks", Style.IndentCaseBlocks);
     IO.mapOptional("IndentGotoLabels", Style.IndentGotoLabels);
     IO.mapOptional("IndentPPDirectives", Style.IndentPPDirectives);
+    IO.mapOptional("IndentRequires", Style.IndentRequires);
     IO.mapOptional("IndentWidth", Style.IndentWidth);
     IO.mapOptional("IndentWrappedFunctionNames",
                    Style.IndentWrappedFunctionNames);
     IO.mapOptional("InsertTrailingCommas", Style.InsertTrailingCommas);
     IO.mapOptional("JavaImportGroups", Style.JavaImportGroups);
     IO.mapOptional("JavaScriptQuotes", Style.JavaScriptQuotes);
     IO.mapOptional("JavaScriptWrapImports", Style.JavaScriptWrapImports);
     IO.mapOptional("KeepEmptyLinesAtTheStartOfBlocks",
LLVMStyle.IncludeStyle.IncludeCategories = {
       {"^(<|\"(gtest|gmock|isl|json)/)", 3, 0},
       {".*", 1, 0}};
   LLVMStyle.IncludeStyle.IncludeIsMainRegex = "(Test)?$";
   LLVMStyle.IncludeStyle.IncludeBlocks = tooling::IncludeStyle::IBS_Preserve;
   LLVMStyle.IndentCaseLabels = false;
   LLVMStyle.IndentCaseBlocks = false;
   LLVMStyle.IndentGotoLabels = true;
   LLVMStyle.IndentPPDirectives = FormatStyle::PPDIS_None;
+  LLVMStyle.IndentRequires = false;
   LLVMStyle.IndentWrappedFunctionNames = false;
   LLVMStyle.IndentWidth = 2;
   LLVMStyle.InsertTrailingCommas = FormatStyle::TCS_None;
   LLVMStyle.JavaScriptQuotes = FormatStyle::JSQS_Leave;
   LLVMStyle.JavaScriptWrapImports = true;
   LLVMStyle.TabWidth = 8;
   LLVMStyle.MaxEmptyLinesToKeep = 1;
   LLVMStyle.KeepEmptyLinesAtTheStartOfBlocks = true;

clang/lib/Format/FormatToken.h

#define LIST_TOKEN_TYPES                                                       \
   TYPE(BinaryOperator)                                                         \
   TYPE(BitFieldColon)                                                          \
   TYPE(BlockComment)                                                           \
   TYPE(CastRParen)                                                             \
   TYPE(ConditionalExpr)                                                        \
   TYPE(ConflictAlternative)                                                    \
   TYPE(ConflictEnd)                                                            \
   TYPE(ConflictStart)                                                          \
+  TYPE(ConstraintJunctions)                                                    \
   TYPE(CtorInitializerColon)                                                   \
   TYPE(CtorInitializerComma)                                                   \
   TYPE(DesignatedInitializerLSquare)                                           \
   TYPE(DesignatedInitializerPeriod)                                            \
   TYPE(DictLiteral)                                                            \
   TYPE(ForEachMacro)                                                           \
   TYPE(FunctionAnnotationRParen)                                               \
   TYPE(FunctionDeclarationName)                                                \
bool isFunctionLikeKeyword() const {
     case tok::kw_return:
     case tok::kw_sizeof:
     case tok::kw_alignof:
     case tok::kw_alignas:
     case tok::kw_decltype:
     case tok::kw_noexcept:
     case tok::kw_static_assert:
     case tok::kw___attribute:
+    case tok::kw_requires:
       return true;
     default:
       return false;
     }
   }
 
   /// Returns \c true if this is a string literal that's like a label,
   /// e.g. ends with "=" or ":".

clang/lib/Format/TokenAnnotator.cpp

void resetTokenMetadata(FormatToken *Token) {
 
     // Reset token type in case we have already looked at it and then
     // recovered from an error (e.g. failure to find the matching >).
     if (!CurrentToken->isOneOf(
             TT_LambdaLSquare, TT_LambdaLBrace, TT_ForEachMacro,
             TT_TypenameMacro, TT_FunctionLBrace, TT_ImplicitStringLiteral,
             TT_InlineASMBrace, TT_JsFatArrow, TT_LambdaArrow, TT_NamespaceMacro,
             TT_OverloadedOperator, TT_RegexLiteral, TT_TemplateString,
-            TT_ObjCStringLiteral))
+            TT_ObjCStringLiteral, TT_ConstraintJunctions))
       CurrentToken->setType(TT_Unknown);
     CurrentToken->Role.reset();
     CurrentToken->MatchingParen = nullptr;
     CurrentToken->FakeLParens.clear();
     CurrentToken->FakeRParens = 0;
   }
 
   void next() {
void determineTokenType(FormatToken &Current) {
     } else if (Current.is(tok::arrow) &&
                Style.Language == FormatStyle::LK_Java) {
       Current.setType(TT_LambdaArrow);
     } else if (Current.is(tok::arrow) && AutoFound && Line.MustBeDeclaration &&
                Current.NestingLevel == 0 &&
                !Current.Previous->is(tok::kw_operator)) {
       // not auto operator->() -> xxx;
       Current.setType(TT_TrailingReturnArrow);
-
+    } else if (Current.is(tok::arrow) && Current.Previous &&
+               Current.Previous->is(tok::r_brace)) {
+      // Concept implicit conversion contraint needs to be treated like
+      // a trailing return type  ... } -> <type>.
+      Current.setType(TT_TrailingReturnArrow);
     } else if (isDeductionGuide(Current)) {
       // Deduction guides trailing arrow " A(...) -> A<T>;".
       Current.setType(TT_TrailingReturnArrow);
     } else if (Current.isOneOf(tok::star, tok::amp, tok::ampamp)) {
       Current.setType(determineStarAmpUsage(
           Current,
           Contexts.back().CanBeExpression && Contexts.back().IsExpression,
           Contexts.back().InTemplateArgument));
if (Tok.is(tok::ampamp) && NextToken->is(tok::l_paren))
       return TT_BinaryOperator;
 
     // This catches some cases where evaluation order is used as control flow:
     //   aaa && aaa->f();
     if (NextToken->Tok.isAnyIdentifier()) {
       const FormatToken *NextNextToken = NextToken->getNextNonComment();
       if (NextNextToken && NextNextToken->is(tok::arrow))
         return TT_BinaryOperator;
     }
 
     // It is very unlikely that we are going to find a pointer or reference type
     // definition on the RHS of an assignment.
     if (IsExpression && !Contexts.back().CaretFound)
       return TT_BinaryOperator;
 
     return TT_PointerOrReference;
   }
if (Style.SpacesInConditionalStatement) {
     if (Left.is(tok::l_paren) && Left.Previous &&
         isKeywordWithCondition(*Left.Previous))
       return true;
     if (Right.is(tok::r_paren) && Right.MatchingParen &&
         Right.MatchingParen->Previous &&
         isKeywordWithCondition(*Right.MatchingParen->Previous))
       return true;
   }
+
+  // requires ( or requires(
+  if (Right.is(tok::l_paren) && Left.is(tok::kw_requires))
+    return spaceRequiredBeforeParens(Right);
+  // requires clause Concept1<T> && Concept2<T>
+  if (Left.is(TT_ConstraintJunctions) && Right.is(tok::identifier))
+    return true;
+
   if (Left.is(tok::l_paren) || Right.is(tok::r_paren))
     return (Right.is(TT_CastRParen) ||
             (Left.MatchingParen && Left.MatchingParen->is(TT_CastRParen)))
                ? Style.SpacesInCStyleCastParentheses
                : Style.SpacesInParentheses;
   if (Right.isOneOf(tok::semi, tok::comma))
     return false;
   if (Right.is(tok::less) && Line.Type == LT_ObjCDecl) {
if (Style.JavaScriptWrapImports || Line.Type != LT_ImportStatement) {
     if (BeforeClosingBrace && (BeforeClosingBrace->is(tok::comma) ||
                                BeforeClosingBrace->isTrailingComment()))
       return true;
   }
 
   if (Right.is(tok::comment))
     return Left.BlockKind != BK_BracedInit &&
            Left.isNot(TT_CtorInitializerColon) &&
            (Right.NewlinesBefore > 0 && Right.HasUnescapedNewline);
   if (Left.isTrailingComment())
     return true;
   if (Right.Previous->IsUnterminatedLiteral)
     return true;
   if (Right.is(tok::lessless) && Right.Next &&
       Right.Previous->is(tok::string_literal) &&
       Right.Next->is(tok::string_literal))
     return true;
+  // Can break after template<> declaration
   if (Right.Previous->ClosesTemplateDeclaration &&
       Right.Previous->MatchingParen &&
-      Right.Previous->MatchingParen->NestingLevel == 0 &&
-      Style.AlwaysBreakTemplateDeclarations == FormatStyle::BTDS_Yes)
+      Right.Previous->MatchingParen->NestingLevel == 0) {
+    // Put concepts on the next line e.g.
+    // template<typename T>
+    // concept ...
+    if (Right.is(tok::kw_concept))
       return true;
+    return (Style.AlwaysBreakTemplateDeclarations == FormatStyle::BTDS_Yes);
+  }
   if (Right.is(TT_CtorInitializerComma) &&
       Style.BreakConstructorInitializers == FormatStyle::BCIS_BeforeComma &&
       !Style.ConstructorInitializerAllOnOneLineOrOnePerLine)
     return true;
   if (Right.is(TT_CtorInitializerColon) &&
       Style.BreakConstructorInitializers == FormatStyle::BCIS_BeforeComma &&
       !Style.ConstructorInitializerAllOnOneLineOrOnePerLine)
     return true;

clang/lib/Format/UnwrappedLineParser.h

private:
   void parseDoWhile();
   void parseLabel(bool LeftAlignLabel = false);
   void parseCaseLabel();
   void parseSwitch();
   void parseNamespace();
   void parseNew();
   void parseAccessSpecifier();
   bool parseEnum();
+  void parseConcept();
+  void parseRequires();
   void parseJavaEnumBody();
   // Parses a record (aka class) as a top level element. If ParseAsExpr is true,
   // parses the record as a child block, i.e. if the class declaration is an
   // expression.
   void parseRecord(bool ParseAsExpr = false);
   void parseObjCMethod();
   void parseObjCProtocolList();
   void parseObjCUntilAtEnd();

clang/lib/Format/UnwrappedLineParser.cpp

void UnwrappedLineParser::parseBlock(bool MustBeDeclaration, bool AddLevel,
   // Munch the closing brace.
   nextToken(/*LevelDifference=*/AddLevel ? -1 : 0);
 
   if (MacroBlock && FormatTok->is(tok::l_paren))
     parseParens();
 
   if (MunchSemi && FormatTok->Tok.is(tok::semi))
     nextToken();
+  else if (FormatTok->is(tok::arrow)) {
+    // Following the } we can find a trailing return type arrow
+    // as part of an implicit conversion constraint.
+    nextToken();
+    parseStructuralElement();
+  }
+
   Line->Level = InitialLevel;
 
   if (PPStartHash == PPEndHash) {
     Line->MatchingOpeningBlockLineIndex = OpeningLineIndex;
     if (OpeningLineIndex != UnwrappedLine::kInvalidIndex) {
       // Update the opening line to add the forward reference as well
       (*CurrentLines)[OpeningLineIndex].MatchingClosingBlockLineIndex =
           CurrentLines->size() - 1;
case tok::at:
         // This branch isn't strictly necessary (the kw_try case below would
         // do this too after the tok::at is parsed above).  But be explicit.
         parseTryCatch();
         return;
       default:
         break;
       }
       break;
+    case tok::kw_concept:
+      parseConcept();
+      break;
+    case tok::kw_requires:
+      parseRequires();
+      break;
     case tok::kw_enum:
       // Ignore if this is part of "template <enum ...".
       if (Previous && Previous->is(tok::less)) {
         nextToken();
         break;
       }
 
       // parseEnum falls through and does not yet add an unwrapped line as an
void UnwrappedLineParser::parseAccessSpecifier() {
   if (FormatTok->isOneOf(Keywords.kw_slots, Keywords.kw_qslots))
     nextToken();
   // Otherwise, we don't know what it is, and we'd better keep the next token.
   if (FormatTok->Tok.is(tok::colon))
     nextToken();
   addUnwrappedLine();
 }
 
+void UnwrappedLineParser::parseConcept() {
+  assert(FormatTok->Tok.is(tok::kw_concept) && "'concept' expected");
+  nextToken();
+  if (!FormatTok->Tok.is(tok::identifier))
+    return;
+  nextToken();
+  if (!FormatTok->Tok.is(tok::equal))
+    return;
+  nextToken();
+  if (FormatTok->Tok.is(tok::kw_requires))
+    parseRequires();
+}
+
+void UnwrappedLineParser::parseRequires() {
+  assert(FormatTok->Tok.is(tok::kw_requires) && "'requires' expected");
+
+  unsigned int OriginalLevel = Line->Level;
+  if (FormatTok->Previous && FormatTok->Previous->is(tok::greater)) {
+    addUnwrappedLine();
+    if (Style.IndentRequires) {
+      Line->Level++;
+    }
+  }
+  nextToken();
+
+  // requires (R range)
+  if (FormatTok->Tok.is(tok::l_paren)) {
+    parseParens();
+    if (Style.IndentRequires && OriginalLevel != Line->Level) {
+      addUnwrappedLine();
+      --Line->Level;
+    }
+  }
+
+  if (FormatTok->Tok.is(tok::l_brace)) {
+    parseBlock(/*MustBeDeclaration=*/false);
+    addUnwrappedLine();
+  } else {
+    // requires Id<T> && Id<T> || Id<T>
+    while (FormatTok->is(tok::identifier)) {
+      nextToken();
+      if (FormatTok->Tok.is(tok::less)) {
+        while (!FormatTok->Tok.is(tok::greater)) {
+          nextToken();
+        }
+        nextToken();
+      }
+      if (FormatTok->Tok.is(tok::l_paren)) {
+        parseParens();
+      }
+      if (FormatTok->Tok.is(tok::l_brace)) {
+        parseBlock(/*MustBeDeclaration=*/false);
+      }
+      if (FormatTok->Tok.is(tok::semi)) {
+        // Eat any trailing semi.
+        nextToken();
+        addUnwrappedLine();
+      }
+      if (!FormatTok->Tok.isOneOf(tok::ampamp, tok::pipepipe)) {
+        if (FormatTok->Previous && !FormatTok->Previous->is(tok::identifier)) {
+          addUnwrappedLine();
+        }
+        if (Style.IndentRequires && OriginalLevel != Line->Level) {
+          --Line->Level;
+        }
+        break;
+      } else
+        FormatTok->setType(TT_ConstraintJunctions);
+
+      nextToken();
+    }
+  }
+}
+
 bool UnwrappedLineParser::parseEnum() {
   // Won't be 'enum' for NS_ENUMs.
   if (FormatTok->Tok.is(tok::kw_enum))
     nextToken();
 
   // In TypeScript, "enum" can also be used as property name, e.g. in interface
   // declarations. An "enum" keyword followed by a colon would be a syntax
   // error and thus assume it is just an identifier.

clang/unittests/Format/FormatTest.cpp

 
 TEST_F(FormatTest, ParsesConfigurationBools) {
   FormatStyle Style = {};
   Style.Language = FormatStyle::LK_Cpp;
   CHECK_PARSE_BOOL(AlignTrailingComments);
   CHECK_PARSE_BOOL(AlignConsecutiveAssignments);
   CHECK_PARSE_BOOL(AlignConsecutiveDeclarations);
   CHECK_PARSE_BOOL(AlignConsecutiveMacros);
   CHECK_PARSE_BOOL(AllowAllArgumentsOnNextLine);
   CHECK_PARSE_BOOL(AllowAllConstructorInitializersOnNextLine);
   CHECK_PARSE_BOOL(AllowAllParametersOfDeclarationOnNextLine);
   CHECK_PARSE_BOOL(AllowShortCaseLabelsOnASingleLine);
   CHECK_PARSE_BOOL(AllowShortEnumsOnASingleLine);
   CHECK_PARSE_BOOL(AllowShortLoopsOnASingleLine);
   CHECK_PARSE_BOOL(BinPackArguments);
   CHECK_PARSE_BOOL(BinPackParameters);
   CHECK_PARSE_BOOL(BreakAfterJavaFieldAnnotations);
EXPECT_EQ(
              "int j;\n"
              "} // namespace\n"
              "  // "
              "would::it::save::you::a::lot::of::time::if_::i::just::gave::up::"
              "and_::went::mad::now",
              Style));
 }
 
+TEST_F(FormatTest, ConceptsAndRequires) {
+  FormatStyle Style = getLLVMStyle();
+  Style.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_None;
+
+  verifyFormat("template <typename T>\n"
+               "concept Hashable = requires(T a) {\n"
+               "  { std::hash<T>{}(a) } -> std::convertible_to<std::size_t>;\n"
+               "};",
+               Style);
+  verifyFormat("template <typename T>\n"
+               "concept bool EqualityComparable = requires(T a, T b) {\n"
+               "  { a == b } -> bool;\n"
+               "};",
+               Style);
+  verifyFormat("template <typename T>\n"
+               "concept bool EqualityComparable = requires(T a, T b) {\n"
+               "  { a == b } -> bool;\n"
+               "  { a != b } -> bool;\n"
+               "};",
+               Style);
+  verifyFormat("template <typename T>\n"
+               "concept bool EqualityComparable = requires(T a, T b) {\n"
+               "  { a == b } -> bool;\n"
+               "  { a != b } -> bool;\n"
+               "};",
+               Style);
+
+  verifyFormat("template <typename It>\n"
+               "requires Iterator<It>\n"
+               "void sort(It begin, It end) {\n"
+               "  //....\n"
+               "}",
+               Style);
+
+  verifyFormat("template <typename T>\n"
+               "concept Large = sizeof(T) > 10;",
+               Style);
+
+  verifyFormat("template <typename T, typename U>\n"
+               "concept FooableWith = requires(T t, U u) {\n"
+               "  typename T::foo_type;\n"
+               "  { t.foo(u) } -> typename T::foo_type;\n"
+               "  t++;\n"
+               "};\n"
+               "void doFoo(FooableWith<int> auto t) {\n"
+               "  t.foo(3);\n"
+               "}",
+               Style);
+  verifyFormat("template <typename T>\n"
+               "concept Context = sizeof(T) == 1;",
+               Style);
+  verifyFormat("template <typename T>\n"
+               "concept Context = is_specialization_of_v<context, T>;",
+               Style);
+  verifyFormat("template <typename T>\n"
+               "concept Node = std::is_object_v<T>;",
+               Style);
+  verifyFormat("template <typename T>\n"
+               "concept Tree = true;",
+               Style);
+
+  verifyFormat("template <typename T> int g(T i) requires Concept1<I> {\n"
+               "  //...\n"
+               "}",
+               Style);
+
+  verifyFormat(
+      "template <typename T> int g(T i) requires Concept1<I> && Concept2<I> {\n"
+      "  //...\n"
+      "}",
+      Style);
+
+  verifyFormat(
+      "template <typename T> int g(T i) requires Concept1<I> || Concept2<I> {\n"
+      "  //...\n"
+      "}",
+      Style);
+
+  verifyFormat("template <typename T>\n"
+               "veryveryvery_long_return_type g(T i) requires Concept1<I> || "
+               "Concept2<I> {\n"
+               "  //...\n"
+               "}",
+               Style);
+
+  verifyFormat("template <typename T>\n"
+               "veryveryvery_long_return_type g(T i) requires Concept1<I> && "
+               "Concept2<I> {\n"
+               "  //...\n"
+               "}",
+               Style);
+
+  verifyFormat(
+      "template <typename T>\n"
+      "veryveryvery_long_return_type g(T i) requires Concept1 && Concept2 {\n"
+      "  //...\n"
+      "}",
+      Style);
+
+  verifyFormat(
+      "template <typename T>\n"
+      "veryveryvery_long_return_type g(T i) requires Concept1 || Concept2 {\n"
+      "  //...\n"
+      "}",
+      Style);
+
+  Style.IndentRequires = true;
+  verifyFormat("template <typename It>\n"
+               "  requires Iterator<It>\n"
+               "void sort(It begin, It end) {\n"
+               "  //....\n"
+               "}",
+               Style);
+  verifyFormat("template <std::size index_>\n"
+               "  requires(index_ < sizeof...(Children_))\n"
+               "Tree auto &child() {\n"
+               "  // ...\n"
+               "}",
+               Style);
+
+  Style.SpaceBeforeParens = FormatStyle::SBPO_Always;
+  verifyFormat("template <typename T>\n"
+               "concept Hashable = requires (T a) {\n"
+               "  { std::hash<T>{}(a) } -> std::convertible_to<std::size_t>;\n"
+               "};",
+               Style);
+
+  verifyFormat("template <class T = void>\n"
+               "  requires EqualityComparable<T> || Same<T, void>\n"
+               "struct equal_to;",
+               Style);
+
+  verifyFormat("template <class T>\n"
+               "  requires requires {\n"
+               "    T{};\n"
+               "    T (int);\n"
+               "  }\n",               
+               Style);
+}
 } // namespace
 } // namespace format
 } // namespace clang