- Handle constructor invocations after new operator in C# correct
- Add test for the case with lambda in constructor arguments after new operator
|1,000 ms||x64 debian > SanitizerCommon-asan-x86_64-Linux.Linux::decorate_proc_maps.cpp|
Script: -- : 'RUN: at line 1'; /var/lib/buildkite-agent/builds/llvm-project/build/./bin/clang --driver-mode=g++ -gline-tables-only -fsanitize=address -m64 -funwind-tables -I/var/lib/buildkite-agent/builds/llvm-project/compiler-rt/test -ldl -g /var/lib/buildkite-agent/builds/llvm-project/compiler-rt/test/sanitizer_common/TestCases/Linux/decorate_proc_maps.cpp -o /var/lib/buildkite-agent/builds/llvm-project/build/projects/compiler-rt/test/sanitizer_common/asan-x86_64-Linux/Linux/Output/decorate_proc_maps.cpp.tmp
|1,350 ms||x64 debian > SanitizerCommon-tsan-x86_64-Linux.Linux::decorate_proc_maps.cpp|
Script: -- : 'RUN: at line 1'; /var/lib/buildkite-agent/builds/llvm-project/build/./bin/clang --driver-mode=g++ -gline-tables-only -fsanitize=thread -m64 -funwind-tables -I/var/lib/buildkite-agent/builds/llvm-project/compiler-rt/test -ldl -g /var/lib/buildkite-agent/builds/llvm-project/compiler-rt/test/sanitizer_common/TestCases/Linux/decorate_proc_maps.cpp -o /var/lib/buildkite-agent/builds/llvm-project/build/projects/compiler-rt/test/sanitizer_common/tsan-x86_64-Linux/Linux/Output/decorate_proc_maps.cpp.tmp
Nit: comments should be full phrases, ending with full stops
Before the patch, this code mistook lambdas in a constructor call for an initialization list.
@eoanermine ping... we need your name/email before we can commit.
(@curdeius, @owenpan, @HazardyKnusperkeks ) we need to have a policy for this, that if we don't get the name for a commit we are happy to land, that we'll do it the old way, and just mention them, Its frustrating for us to waste our time doing reviews only to fall at the last hurdle. (@aaron.ballman any thoughts)
Good idea on starting a policy for this. I think that policy should be discussed by the community via an RFC because we should be consistent across the project in how we handle this sort of situation, IMO (at least within the clang part of the repo; it'd be weird for the static analyzer to have a different policy from Clang which is different from clang-format). Personally, I think if there's been no response for a month, we're probably fine to commandeer the patch. That should be sufficient time for folks who have gone on vacation to have come back and responded, hopefully. I think the only situation where we might want a more tight timeframe is when the patch is critical (blocking a release kind of thing), but hopefully that situation is so rare as to not require making a policy for it.