[clang] [clang] Add test for CWG1807 (PR #77637)

[Vlad Serebrennikov via cfe-commits]

Endilll wrote:

Following the suggestion from @nikic, I prepared two variants of the same test, one hard-written, and one using `update_cc_test_checks.py` (with heavy manual editing afterwards). Hand-written:
```
// CHECK-LABEL:      define dso_local void @dr1807::f()
// CHECK:              invoke void @dr1807::S::S(){{.+}}
// CHECK-NEXT:         {{.+}} unwind label %lpad
// CHECK-LABEL:      lpad:
// CHECK:              br {{.+}}, label {{.+}}, label %arraydestroy.body
// CHECK-LABEL:      arraydestroy.body:
// CHECK:              [[ARRAYDESTROY_ELEMENT:%.*]] = getelementptr {{.+}}, i64 -1
// CXX98-NEXT:         invoke void @dr1807::S::~S(){{.*}}[[ARRAYDESTROY_ELEMENT]]
// SINCE-CXX11-NEXT:   call void @dr1807::S::~S(){{.*}}[[ARRAYDESTROY_ELEMENT]]
```
Script:
```
// CHECK-LABEL:      define dso_local void @dr1807::f()(
// CHECK:              invoke void @dr1807::S::S()(ptr noundef nonnull align 1 dereferenceable(1) [[ARRAYCTOR_CUR:%.*]])
// CHECK-NEXT:                 to label [[INVOKE_CONT:%.*]] unwind label [[LPAD:%.*]]
// CHECK-LABEL:      lpad:
// CHECK:              br i1 [[ARRAYDESTROY_ISEMPTY:%.*]], label [[ARRAYDESTROY_DONE2:%.*]], label [[ARRAYDESTROY_BODY:%.*]]
// CHECK-LABEL:      arraydestroy.body:
// CHECK:              [[ARRAYDESTROY_ELEMENT]] = getelementptr inbounds %"struct.dr1807::S", ptr [[ARRAYDESTROY_ELEMENTPAST]], i64 -1
// CXX98-NEXT:         invoke void @dr1807::S::~S()(ptr noundef nonnull align 1 dereferenceable(1) [[ARRAYDESTROY_ELEMENT]])
// CXX98-NEXT:                 to label [[INVOKE_CONT1]] unwind label [[TERMINATE_LPAD:%.*]]
// SINCE-CXX11-NEXT:   call void @dr1807::S::~S()(ptr noundef nonnull align 1 dereferenceable(1) [[ARRAYDESTROY_ELEMENT5:.*]]) #[[ATTR2:.*]]
```
In my opinion, script captures way too much, diluting the point of the test. For example, `i64 -1` is a crucial part of the test, but it's much easier to miss it in lengthy script output. (Searching for it might be a good exercise for the reader.) I'd also like to note that target audience of DR tests is likely to be far less experienced in reading LLVM IR than regular users of the script, so it's much less obvious for them to know which parts of the output to pay attention to. On the other hand wildcards help hide uninteresting parts of the codegen output, highlighting what's important.

This brings me to conclusion that hand-written style of codegen tests presented above is a better fit for purposes of C++ defect report codegen tests.

CC @AaronBallman 

https://github.com/llvm/llvm-project/pull/77637