OK, will do it by the end of this week.

D158372 addresses comments.

I’ll see what I can do regarding reviving the string concat behavior. It feels like that a more refined treatment than before can be achieved. Maybe adds an imaginary preceding whitespace only when we can find a macro with the same name.

In D153156#4599324, @jyknight wrote:

If proper spec-conformance means we can no longer support the ability to allow such out-of-spec pre-c++11 code to work anymore, that's probably OK...but, in that case, we also need to eliminate the warning option, and mention the change in the release notes.

Works in C++98 mode tho. TIL people exploit this to mix pre-C++11 code into modern C++. I agree that a reminder for those people in the release note is needed.

And, if that _was_ an intended change, then we have other diagnostics which need to be fixed up now

Agreed

In D153156#4598915, @steelannelida wrote:

Unfortunately the option -Wno-reserved-user-defined-literal fails after this:

#define MYTHING "_something_"

const char* f() {
  return "ONE"MYTHING"TWO";
}

$ clang -Wno-reserved-user-defined-literal repro.cxx
repro.cxx:4:15: error: no matching literal operator for call to 'operator""MYTHING' with arguments of types 'const char *' and 'unsigned long', and no matching literal operator template
    4 |   return "ONE"MYTHING"TWO";
      |               ^
1 error generated.

Thank Aaron and Vlad for reviewing this! Just updating the diff to reflect the final version.

Thanks for all the suggestions and review comments!

Refactor VisitCXXOperatorCallExpr and mark CWG2571 as done in Clang 15 (deliberately the same version P2128R6 was implemented) since this patch only fix the diagnostics around it.

Thanks for the reminder. I am aware of that. Browsing through 762672a73a1e and a560ccf2af7a, I believe the indeterminately sequenced requirement is met, neither of which test the codegen so I might just put the example shown in the release note in dr25xx.cpp.

Addressed comments

BTW, I am not sure if CWG2571 is implemented by @cor3ntin? If so, can we mark it as done on https://clang.llvm.org/cxx_dr_status.html#2571? This patch handles the warning around it tho.

Improve the test.

https://eel.is/c++draft/namespace.std#7 is in the library clause.
Couldn't find a better place to put the test other than clang/test/CXX/dcl.dcl/basic.namespace/namespace.def/p7.cpp which is for https://eel.is/c++draft/namespace.def.general#4.sentence-2.

Put -Windeterminately-sequenced under -Wsequence-point's control

Gentle ping :)

There seems to be no clear objection to this and https://reviews.llvm.org/D152632 and the CI are passing for both. Any chance that I merge these two before llvm 17 branch out (IIRC the next Monday)?

Hmm… I don’t see why check-format keeps failing. I git clang-format thrice before uploading.
https://buildkite.com/llvm-project/premerge-checks/builds/164452

co_awaiting https://reviews.llvm.org/D152632 to pass CI to see if this patch fixes the issues...

-Wdeprecated-literal-operator will be on by default in https://reviews.llvm.org/D153156
This one is now blocked by the libc++ fix: https://reviews.llvm.org/D155200

In D152632#4443284, @shafik wrote:

I am wondering why we don't fold this into -Wreserved-identifier

Reverse the dependency chain.

Defaults to on for C++23 only. Enable for all the language modes in another patch.

Depends on D153156

Looks like this breaks check-clang on Mac: http://45.33.8.238/macm1/62779/step_7.txt

Overhaul for dr25xx.cpp.

Addressed comments.
Thanks for letting me know how to structure tests for DRs.

Few questions:
I think this applies to all the language modes?
Somehow, https://wg21.link/CWG2521 is not redirecting to https://cplusplus.github.io/CWG/issues/2521.html. Is this normal?

In D139586#4324857, @cor3ntin wrote:

@rZhBoYao are you still working on this? Thanks!

Consider:

struct T {
  const int *begin() const;
  const int *end()   const;
  T &r() [[clang::lifetimebound]];
  T t();
};

Revisiting @ChuanqiXu 's code suggestion...

Reordered enumerators.

Added release note.

Updating the status of CWG 1394 is the only change.

Removed member function test cases and addressed comments,
which includes:

1. Sema::SetFunctionBodyKind
2. Change enum names
3. Be clear about delete being C++ specific.

Handling of eagerly parsed deleted or defaulted function must happen AFTER D.complete(Res);.

I think an extra parameter is inevitable without complicating things too much.

Added an entry in release notes. Waiting for CI...

By 'release notes' do you mean a more detailed commit message?

This passes check-clang-semacxx on my machine.

Diagnose "same name as its class" before setting the declarator invalid as otherwise it would not be diagnosed. This also aligns with gcc's behavior.

Don't break template declarations.
re-clang-format

The previous diff was indeed very specific and doesn't handle

template <typename T>
struct A {
  A(void*) {}
  T A<T>{}; // expected-error{{member 'A' cannot have template arguments}}
};

Thank you all for spending time reviewing this!

Hi all, I found this patch causing PR52702 in that the parent of this commit and LLDB 12 worked fine.
When disassembling a hello world C program on Linux, LLDB used to show
callq 0x401030 ; symbol stub for: puts
instead of
callq 0x401030 ; symbol stub for: ___lldb_unnamed_symbol36.
Examining the symbol table by running lldb -b -o 'image dump symtab' a.out used to show:

[   18]     20   X Undefined       0x0000000000000000                    0x0000000000000000 0x00000012 puts@GLIBC_2.2.5
                         ........
[   33]     35   X Code            0x0000000000401000                    0x000000000000001b 0x00000212 _init
[   34]     36  S  Trampoline      0x0000000000401030                    0x0000000000000010 0x00000000 puts
[   35]     37  SX Code            0x0000000000401020                    0x0000000000000010 0x00000000 ___lldb_unnamed_symbol1$$a.out

and now (ToT and LLDB 13) it's:

[   18]     20   X Undefined       0x0000000000000000                    0x0000000000000000 0x00000012 puts@GLIBC_2.2.5
                         ........
[   33]     35   X Code            0x0000000000401000                    0x000000000000001b 0x00000212 _init
[   34]     36  S  Trampoline      0x0000000000401030                    0x0000000000000010 0x00000000 ___lldb_unnamed_symbol36
[   35]     37  SX Code            0x0000000000401020                    0x0000000000000010 0x00000000 ___lldb_unnamed_symbol37

image dump symtab libc.so.6 gives similar result.
Before ec1a4917 :

[ 2366]   2367  S  Trampoline      0x0000000000025010 0x00007ffff7df2010 0x0000000000000010 0x00000000 realloc
[ 2367]   2368  S  Trampoline      0x0000000000025020 0x00007ffff7df2020 0x0000000000000010 0x00000000 __tls_get_addr
[ 2368]   2369  S  Trampoline      0x0000000000025030 0x00007ffff7df2030 0x0000000000000010 0x00000000 memalign
[ 2369]   2370  S  Trampoline      0x0000000000025040 0x00007ffff7df2040 0x0000000000000010 0x00000000 _dl_exception_create
[ 2370]   2371  S  Trampoline      0x0000000000025050 0x00007ffff7df2050 0x0000000000000010 0x00000000 __tunable_get_val
[ 2371]   2372  S  Trampoline      0x0000000000025060 0x00007ffff7df2060 0x0000000000000010 0x00000000 _dl_find_dso_for_object
[ 2372]   2373  S  Trampoline      0x0000000000025070 0x00007ffff7df2070 0x0000000000000010 0x00000000 calloc
[ 2373]   2373  SX Code            0x0000000000025000 0x00007ffff7df2000 0x0000000000000010 0x00000000 ___lldb_unnamed_symbol1$$libc.so.6
[ 2374]   2373  SX Code            0x0000000000025300 0x00007ffff7df2300 0x0000000000000040 0x00000000 ___lldb_unnamed_symbol2$$libc.so.6
[ 2375]   2373  SX Code            0x0000000000025340 0x00007ffff7df2340 0x00000000000002f0 0x00000000 ___lldb_unnamed_symbol3$$libc.so.6
[ 2376]   2373  SX Code            0x0000000000025630 0x00007ffff7df2630 0x000000000000000c 0x00000000 ___lldb_unnamed_symbol4$$libc.so.6

After:

[ 2366]   2367  S  Trampoline      0x0000000000025010 0x00007ffff7df2010 0x0000000000000010 0x00000000 ___lldb_unnamed_symbol2367
[ 2367]   2368  S  Trampoline      0x0000000000025020 0x00007ffff7df2020 0x0000000000000010 0x00000000 ___lldb_unnamed_symbol2368
[ 2368]   2369  S  Trampoline      0x0000000000025030 0x00007ffff7df2030 0x0000000000000010 0x00000000 ___lldb_unnamed_symbol2369
[ 2369]   2370  S  Trampoline      0x0000000000025040 0x00007ffff7df2040 0x0000000000000010 0x00000000 ___lldb_unnamed_symbol2370
[ 2370]   2371  S  Trampoline      0x0000000000025050 0x00007ffff7df2050 0x0000000000000010 0x00000000 ___lldb_unnamed_symbol2371
[ 2371]   2372  S  Trampoline      0x0000000000025060 0x00007ffff7df2060 0x0000000000000010 0x00000000 ___lldb_unnamed_symbol2372
[ 2372]   2373  S  Trampoline      0x0000000000025070 0x00007ffff7df2070 0x0000000000000010 0x00000000 ___lldb_unnamed_symbol2373
[ 2373]   2374  SX Code            0x0000000000025000 0x00007ffff7df2000 0x0000000000000010 0x00000000 ___lldb_unnamed_symbol2374
[ 2374]   2375  SX Code            0x0000000000025300 0x00007ffff7df2300 0x0000000000000040 0x00000000 ___lldb_unnamed_symbol2375
[ 2375]   2376  SX Code            0x0000000000025340 0x00007ffff7df2340 0x00000000000002f0 0x00000000 ___lldb_unnamed_symbol2376
[ 2376]   2377  SX Code            0x0000000000025630 0x00007ffff7df2630 0x000000000000000c 0x00000000 ___lldb_unnamed_symbol2377

Is this intended for the performance boost? It seems to me that "S Trampoline" symbols should be handled differently.

Can you commit this for me? My name and email: PoYao Chang <rZhBoYao@gmail.com>.
And thank you for your time!

Address inline comment.