Regression in clang-format-17

[prj-]

$ cat source.h 
template <bool other_is_const_it, util::enable_if_t<is_const_it && !other_is_const_it> * = nullptr>
table_iterator(const table_iterator<other_is_const_it> &other) noexcept : table_iterator(other.map_, other.it_)
{
}
$ clang-format --style=file:clang-format.txt source.h > 16.h
$ clang-format --version
clang-format version 16.0.1
$ clang-format-17 --style=file:clang-format.txt source.h > 17.h
$ clang-format-17 --version
Debian clang-format version 17.0.0 (++20230404111547+e45523cd218f-1~exp1~20230404111707.1206)
$ diff -Naur 16.h 17.h
--- 16.h	2023-04-11 07:20:48
+++ 17.h	2023-04-11 07:21:17
@@ -1,4 +1,4 @@
-template <bool other_is_const_it, util::enable_if_t<is_const_it && !other_is_const_it> * = nullptr>
+template <bool other_is_const_it, util::enable_if_t<is_const_it &&!other_is_const_it> * = nullptr>
 table_iterator(const table_iterator<other_is_const_it> &other) noexcept : table_iterator(other.map_, other.it_)
 {
 }

clang-format.txt is attached.

[llvmbot]

@llvm/issue-subscribers-clang-format

[rymiel]

Bisected to bb4f6c4, which is my commit, sorry

[rymiel]

It appears this is symptoms of a bigger bug. When I made that patch, I assumed that modifyContext.AssignmentStartsExpression would only touch the right side of the equals sign, since that's what the "starts" implies. Turns out it also affects the left side's formatting.

For example:

foo<a &&b>::x = 0;

I am 80% sure this could be valid C++ syntax in some cryptic scenario (a class with a NTTP, and an assignment to a static member variable). The && on the left hand side becomes a PointerOrReference due to AssignmentStartsExpression polluting it.

It also just so happens that this somewhat cryptic pattern is actually not that cryptic when dealing with SFINAE magic.

EDIT:

You don't even need cryptic syntax. Going by the original bug's syntax, even this is enough:

foo<a &&b> *c = nullptr;

EDIT2:

Nevermind, this has nothing to do with contexts, there just a strange correcting term that is run right after AssignmentStartsExpression that causes this.

[rymiel]

Patch: https://reviews.llvm.org/D148024