[Clang] Implement P2865R6 (Remove Deprecated Array Comparisons from C++26)

[cor3ntin]

Paper link: https://isocpp.org/files/papers/P2865R6.pdf

We implement the depreciation warning, we need to turn it into an error https://godbolt.org/z/sqod3G69P.

TODO:

• Adding an error diagnostics in C++26 mode (while keeping the existing depreciation warning in older language modes)
• Adding tests
• Modifying cxx_status.html
• Adding changelog entry

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: cor3ntin (cor3ntin)

Paper link: https://isocpp.org/files/papers/P2865R6.pdf

We implement the depreciation warning, we need to turn it into an error https://godbolt.org/z/sqod3G69P.

TODO:

• Adding an error diagnostics in C++26 mode (while keeping the existing depreciation warning in older language modes)
• Adding tests
• Modifying cxx_status.html
• Adding changelog entry

[llvmbot]

Hi!

This issue may be a good introductory issue for people new to working on LLVM. If you would like to work on this issue, your first steps are:

1. Check that no other contributor has already been assigned to this issue. If you believe that no one is actually working on it despite an assignment, ping the person. After one week without a response, the assignee may be changed.
2. In the comments of this issue, request for it to be assigned to you, or just create a pull request after following the steps below. Mention this issue in the description of the pull request.
3. Fix the issue locally.
4. Run the test suite locally. Remember that the subdirectories under test/ create fine-grained testing targets, so you can e.g. use make check-clang-ast to only run Clang's AST tests.
5. Create a Git commit.
6. Run git clang-format HEAD~1 to format your changes.
7. Open a pull request to the upstream repository on GitHub. Detailed instructions can be found in GitHub's documentation. Mention this issue in the description of the pull request.

If you have any further questions about this issue, don't hesitate to ask via a comment in the thread below.

[llvmbot]

@llvm/issue-subscribers-good-first-issue

Author: cor3ntin (cor3ntin)

Paper link: https://isocpp.org/files/papers/P2865R6.pdf

We implement the depreciation warning, we need to turn it into an error https://godbolt.org/z/sqod3G69P.

TODO:

• Adding an error diagnostics in C++26 mode (while keeping the existing depreciation warning in older language modes)
• Adding tests
• Modifying cxx_status.html
• Adding changelog entry

[AmrDeveloper]

I can work on it, i am already working on -warray-comparion in this issue and i can support C++26 error case after it

[AaronBallman]

Adding an error diagnostics in C++26 mode (while keeping the existing depreciation warning in older language modes)

We should discuss this more. I think this should be a warning which defaults to an error rather than a hard error unless there's a really good reason not to. We know we still have people with code using these comparisons -- for example: https://sourcegraph.com/github.com/mongodb/mongo/-/blob/src/third_party/icu4c-57.1/source/BUILD.bazel?L28-30

We can then strengthen to an error in a release or two once folks have gotten the stronger message. WDYT?

[cor3ntin]

I think this should be a warning which defaults to an error rather than a hard error unless there's a really good reason not to

That seems reasonable - Note that it probably doesn't supper matter as C++26 is unlikely to be widely used.

[frederick-vs-ja]

Hmm... Given P2865R6 (implicitly) requires changes in SFINAE, would it be burdensome for Clang to accept such comparison in some cases while considering it as substitution failure?

[AaronBallman]

Hmm... Given P2865R6 (implicitly) requires changes in SFINAE, would it be burdensome for Clang to accept such comparison in some cases while considering it as substitution failure?

Possibly, but my intuition isn't very strong here. My biggest concern would be that we'd need ABI tags so folks can opt in to the old behavior or the new behavior in order to not get silent (ABI impacting) behavioral changes.