Skip to content

[clang-format] Make bitwise and imply requires clause #110942

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Oct 22, 2024
Merged

[clang-format] Make bitwise and imply requires clause #110942

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
ef604d0
[clang-format] Make some binary operations imply requires clause
rymiel Oct 3, 2024
64b9240
Reduce scope of PR
rymiel Oct 10, 2024
d06b7c9
clean up tests
rymiel Oct 21, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions clang/lib/Format/UnwrappedLineParser.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3528,6 +3528,17 @@ bool UnwrappedLineParser::parseRequires() {
return false;
}
break;
case tok::equalequal:
case tok::greaterequal:
case tok::lessequal:
case tok::r_paren:
case tok::pipepipe:
if (OpenAngles == 0) {
FormatTok = Tokens->setPosition(StoredPosition);
parseRequiresClause(RequiresToken);
return true;
}
break;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead, how about just moving case tok::amp: up?

--- a/clang/lib/Format/UnwrappedLineParser.cpp
+++ b/clang/lib/Format/UnwrappedLineParser.cpp
@@ -3474,10 +3474,10 @@ bool UnwrappedLineParser::parseRequires() {
   case tok::r_paren:
   case tok::kw_noexcept:
   case tok::kw_const:
+  case tok::amp:
     // This is a requires clause.
     parseRequiresClause(RequiresToken);
     return true;
-  case tok::amp:
   case tok::ampamp: {
     // This can be either:
     // if (... && requires (T t) ...)

The rationale is that it doesn't make sense to bitwise-and another expression with a requires expression.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then wouldn't r-value reference methods still be broken? Those still exist even if they're rare. I mean, we can do both

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My suggested change (in place of yours) passes all the existing tests and the new tests you add here. Can you give a counterexample?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about the original issue but with an r-value ref-qualifier instead of an l-value one:

template <int n> struct S
{
  void f() && requires(n == 1) {}

  // some comment
  void g() {}
};

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nvm. This would fail:

template <int n> struct S
{
  void f() &&
  requires(n == 1)
  {
  }

  // some comment
  void g() {}
};

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about < and >?

template <int n> struct S {
  void f() &
    requires(n < 1)
  {}

  // some comment
  void g() {}
};

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It gets complicated with template parameters :(
Like I said in the pr description, it's probably a better idea to redo that whole lookahead thing to be a little more smart. But I also don't have the energy for that so I just offered this bandaid fix

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we are doing a limited fix now, maybe just move the case tok::amp: up as suggested above? It would cover patterns similar to that in #110485 no matter what operator is used in the parenthesized expression after & requires.

case tok::eof:
// Break out of the loop.
Lookahead = 50;
Expand Down
15 changes: 15 additions & 0 deletions clang/unittests/Format/TokenAnnotatorTest.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1296,6 +1296,21 @@ TEST_F(TokenAnnotatorTest, UnderstandsRequiresClausesAndConcepts) {
Tokens = annotate("bool x = t && requires(Foo<C1 || C2> x) { x.foo(); };");
ASSERT_EQ(Tokens.size(), 25u) << Tokens;
EXPECT_TOKEN(Tokens[5], tok::kw_requires, TT_RequiresExpression);

// Second function definition is required due to lookahead
Tokens = annotate("void f() & requires(n == 1) {}\nvoid g();");
ASSERT_EQ(Tokens.size(), 19u) << Tokens;
EXPECT_TOKEN(Tokens[4], tok::amp, TT_PointerOrReference);
EXPECT_TOKEN(Tokens[5], tok::kw_requires, TT_RequiresClause);

Tokens = annotate("void f() & requires(n || h) {}\nvoid g();");
ASSERT_EQ(Tokens.size(), 19u) << Tokens;
EXPECT_TOKEN(Tokens[4], tok::amp, TT_PointerOrReference);
EXPECT_TOKEN(Tokens[5], tok::kw_requires, TT_RequiresClause);

Tokens = annotate("bool x = t && requires(F<n == 1> x) { x.foo(); };");
ASSERT_EQ(Tokens.size(), 25u) << Tokens;
EXPECT_TOKEN(Tokens[5], tok::kw_requires, TT_RequiresExpression);
}

TEST_F(TokenAnnotatorTest, UnderstandsRequiresExpressions) {
Expand Down
Loading