It's just that it seemed weird/hacky to use asm just to stick assembler directives in the middle of the generated code instead of actual assembly, so I generated an assembly version and cleaned it up a bit. I'm happy to go back to the original shorter C++ version if that's not a concern.

Added a test case that seems to work well with the existing testing setup if I rebuild LLVM with ASan enabled. I have checked out other usages of .cfi_* directives in other LLVM assembly test files and they seem to run them through some llvm tool with -triple <something including linux>, so I have added a REQUIRES: linux line to avoid breakage.

Looking into how to add a test now. I'm not familiar at all with libunwind code, so I have no idea how to cause this leak to happen from the outside (and then the test would only work when running under asan). Any pointers would be much appreciated.

FYI we have detected a 2-3% performance regression on Haswell machines in test-suite/MicroBenchmarks/ImageProcessing/Interpolation that seems to be caused by this commit.

Hm, I just realized I'm undoing https://reviews.llvm.org/D58883.

About %T not working for "process launch", what about something like RUN: %lldb -b --one-line-before-file "process launch --stdout %T/x86-zmm-write.out" -s %s %t and then FileCheck-ing?

Fixed indentation.

Removed trailing blank lines from test case, will commit now. Thanks for the review!

Added a new test that checks that, when a full path to a compiler is specified:

Thanks for the fix!

Thanks! Please let me know if it happens again and I'll try my best to debug it.

Increased wait time in test binary for TestVSCode_attach.py from 5 to 10 seconds.

I considered assigning it to a std::string, but GetCString() can return a null pointer and I'm not sure you can construct a std::string directly from that.

I reverted this patch on r350787

I think this change just broke the clang build:

Folded the two test cases (capturing an invalid type and capturing an invalid array type) into a single file.

Added a test for the "capturing an array of incomplete type" case. See also responses to inline comments below.

Fixed some issues pointed out in review comments:

• call to getBaseElementType before checking type validity.
• when the type is incomplete, mark not only the lambda closure type as invalid but also the field

I think this change is breaking one of our builds. The attached reduced test case fails with the current trunk revision if built with "clang -x c -O2 -mavx -c crash.ii".