Update the SemaChecking.cpp and the test.

1. Simplify code in SemaChecking.cpp
2. Fix the nit and rename the variable in SemaChecking.cpp
3. Update the condition in SemaChecking.cpp
4. Add wchar_t test to show our care

Update algorithm.inc to pass prechecks

Correct the #if condition for ranges::starts_with() and ranges::ends_with()

change #if TEST_STD_VER > 20 to #if TEST_STD_VER >= 23

Update tests

Modify algorithm.inc to pass the presubmit

Remove unused header files

remove redundant headers to avoid transitive includes

Reformat

1. add some headers in ranges_ends_with.h
2. fix nits: add/remove some blank lines
3. remove useless headers in ranges.ends_with.pass.cpp

Update benchmark tests

Remove c++ related conditions

update comments

add #include_next

update the reformat msg and tests

Reformat the error msg

Update test

Update benchmarks test

Update HasEndsWithR test

reformat

1. reformat
2. rename helper function
3. add std::move

Remove the short type check part.
From Aaron Ballman:

Instead, we'd want to do some data flow analysis (in the clang static analyzer) so we know the potential range of values of each of the operands and can diagnose the result type from there if we can prove there's a potential for overflow due to type confusion.

1. Remove pure integer check to the right place
2. Update error msg and all related tests
3. Add explanations to header file

Add integer type test and update c2x tests.

Prevent result type from being short and fix the breaking in builtinoverflow.cpp

Rename the warn_overflow_builtin_can_not_be_short for precision

Get ranges::equal optimization back when the iterator is random access iterator, and add a benchmark test to verify the optimization works.

1. define STDC_VERSION_STDCKDINT_H
2. check short type

1. Reformat test files in C/C2x
2. Update the definition and the test about __STDC_VERSION_STDCKDINT_H__
3. Update release docs and the introduction in the test file
4. Update RUN command in the test files
5. Update PPDirectives.cpp

1. use ranges::size() instead of ranges::distance to get the size of an array at constant time
2. remove std::move for all input which call ranges algorithms.

Update else to make it a bit leaner to compile.

add a comment to make code more clear

Pass by referrence

Reformat clang/lib/Lex/PPDirectives.cpp. I use git-clang-format due to previous pre-check failure but lots of modifications in clang/lib/Lex/ directory. Should I keep running git-clang-format if the pre-check fails again?

Skip static_assert() tests because constexpr is not supported in C23 yet: https://github.com/llvm/llvm-project/issues/64742

1. separate two files in clang/test/C/C2x
2. make some update about the macro STDC_VERSION_STDCKDINT_H add the test for testing it

1. rename to .c file
2. create clang/test/C/C2x/n2683.c and add codegen tests and semantic tests
3. update clang/docs/ReleseNotes.rst
4. update clang/www/c_status.html
5. reformat PPDirectives.cpp
6. set STDC_VERSION instead of gnu

In D157331#4576540, @aaron.ballman wrote:

In D157331#4575224, @ZijunZhao wrote:

Another followup question: I check https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2683.pdf and I only add Core Proposal here. Do I need to add Supplemental Proposal, like some types?

Ah, this is a bit confusing! tl;dr: No need to add the supplemental proposal.

The way to trace this down yourself is:

• The working draft (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf) has a list of what papers were adopted and applied to the standard. You'll find N2683 under the June 2021 virtual meeting heading. That's how you know which paper was adopted.
• You can look at the paper to see the proposed wording, prior art, motivation, etc. That gets you 95% of the way but you need to know what words actually went into the standard. So use the original paper to give you ideas on what to implement, what to test, etc, but verify against the wording in the standard.
• Because this was discussed at the June 2021 virtual meeting, you should look at those meeting minutes (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2802.pdf) to see what was adopted. You can search for 2683 to find the relevant discussion in the minutes. Most importantly, you can see what polls were taken. The two polls of interest were:

Straw Poll: Does the committee wish to adopt the Core proposal from N2683 into C23? 13-0-5 Core proposal goes into C23.
Straw Poll: Does the committee want the "ckd_" identifiers from N2683's Core proposal in future library directions to be potentially reserved identifiers? 18-0-0

This is how we know that only the core proposal was added, and not the supplemental proposal. Checking that belief against the standard wording itself verifies that only the core proposal was added and the supplemental bits are left out.

(Hopefully that explanation makes some sense, but if you have more questions, just ask!)

Another followup question: I check https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2683.pdf and I only add Core Proposal here. Do I need to add Supplemental Proposal, like some types?

1. Fix some format nits
2. Change CHECK-NEXT to CHECK

1. If we can get the size of input directly, get it, then compare the sizes and return the result in some cases. Otherwise, go to step2.
2. If the input is bidirectional, go to __bidirectional_impl() directly. If not, go to step 3
3. Call ranges::equal() to get the result

1. Optimize when input is bidirectional iterator.
2. Reformat test file

1. Test input_iterators
2. Update help function (will try to optimize later)
3. some nits fixed

1. use ranges::advance() rather than std::advance()
2. add two test cases: range consists of just one element and suffix consists of just one element
3. remove the duplicated test case about predicate

delegate to the non-range overload of operator()

Fix some nits:

1. delete duplication
2. call ranges::equal in the implementation
3. use decltype
4. add some tests

replace ranges::drop_view with ranges::subrange

make some changes on tests

update all the robust_against_* tests but no need for robust_against_dangling one

make some format changes

Submit: https://github.com/llvm/llvm-project/commit/205175578e0d73b4cd63d4d124a900fff10da7f8

Submit: https://github.com/llvm/llvm-project/commit/f9f1f9c2a533d5caa3ddf813ebbd16fe3a13fce7