Skip to content
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.

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

clang-format-18 ColumnLimit: 0 breaks formatting when encountering empty #if 0 ... #endif section #68404

Closed
MartinsSmirnovs opened this issue Oct 6, 2023 · 2 comments · Fixed by #69473
Assignees

Comments

@MartinsSmirnovs
Copy link

MartinsSmirnovs commented Oct 6, 2023

Given following .clang-format file:

ColumnLimit: 0

And following foo.cpp source file:

struct Foo {
  Foo() : a(2) {
#if 0
    // comment
#endif
  }

  Foo &operator+=(const Foo &) {
    return *this;
  }

  int a = 0;
};

I expect that clang-format-18 foo.cpp will not perform formatting (or at least not in a broken way), however, it does:

$ clang-format-18 foo.cpp 
struct Foo {
  Foo() : a(2){
#if 0
    // comment
#endif
          }

          Foo
          & operator+=(const Foo &) {
    return *this;
  }

  int a = 0;
};

After changing the value of ColumnLimit: 0 to something like 80, the issue is no more. We can also add some code into the #if 0 part, and clang-format will not perform formatting in broken way anymore with ColumnLimit: 0.
clang-format-18 version:

$ clang-format-18 --version
Ubuntu clang-format version 18.0.0 (++20230929042255+ab472cd4ea12-1~exp1~20230929042400.1214)
@weltschildkroete
Copy link
Contributor

Bisected to e9ed1aa.

@owenca
Copy link
Contributor

owenca commented Oct 17, 2023

@rymiel

@rymiel rymiel self-assigned this Oct 18, 2023
rymiel added a commit to rymiel/llvm-project that referenced this issue Oct 18, 2023
Pull request llvm#65409 changed the brace kind heuristic to not treat a
preprocessor if directive as a in statement, however, this caused some
regressions.

If the contents of a brace don't immediately determine the brace kind,
the heuristic will look at the characters immediately before and after
the closing brace to determine the brace type.

Unfortunately, if the closing brace was preceded by a preprocessor
directive, for example `#endif`, the preceding token was `endif`, seen
as just an identifier, so the braces were understood as a braced list.

This patch fixes this behaviour by skipping all preprocessor directives
when calculating brace types. Comments were already being skipped, so
now preprocessor lines are skipped alongside comments.

Fixes llvm#68404
rymiel added a commit that referenced this issue Nov 3, 2023
Pull request #65409 changed the brace kind heuristic to not treat a
preprocessor if directive as a in statement, however, this caused some
regressions.

If the contents of a brace don't immediately determine the brace kind,
the heuristic will look at the characters immediately before and after
the closing brace to determine the brace type.

Unfortunately, if the closing brace was preceded by a preprocessor
directive, for example `#endif`, the preceding token was `endif`, seen
as just an identifier, so the braces were understood as a braced list.

This patch fixes this behaviour by skipping all preprocessor directives
when calculating brace types. Comments were already being skipped, so
now preprocessor lines are skipped alongside comments.

Fixes #68404
qihangkong pushed a commit to rvgpu/llvm that referenced this issue Apr 18, 2024
Pull request #65409 changed the brace kind heuristic to not treat a
preprocessor if directive as a in statement, however, this caused some
regressions.

If the contents of a brace don't immediately determine the brace kind,
the heuristic will look at the characters immediately before and after
the closing brace to determine the brace type.

Unfortunately, if the closing brace was preceded by a preprocessor
directive, for example `#endif`, the preceding token was `endif`, seen
as just an identifier, so the braces were understood as a braced list.

This patch fixes this behaviour by skipping all preprocessor directives
when calculating brace types. Comments were already being skipped, so
now preprocessor lines are skipped alongside comments.

Fixes llvm/llvm-project#68404
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants