This was previously piggybacking on whatever happened to be the last
location set on CGDebugInfo/DIBuilder, which was wrong (it was often the
current location, such as the 'fn()' call site, not the end of the
block). With my improvements to set/unset the location in a scoped
manner (r225000) this went from a bad quality situation, to a crash.
Fixing this goes part-way to unblocking the recommit of r225000.
It's likely that any call to CodeGenFunction::StartFunction without the
CurEHLocation set represents a similar bug or risk of a bug. Perhaps
there are some callers that know they won't generate EH cleanups, but
I'm not sure.
I considered a generic catch-fix in StartFunction (just fallback to the
GlobalDecl's location) but that seemed like it'd mask bugs where the EH
location shouldn't be the same as the decl's location (& indeed by not
using that stop-gap I found this bug). We'll see how long I can hold out
on the generic catch-all. I might eventually be able to add an assertion
in.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225845
91177308-0d34-0410-b5e6-
96231b3b80d8
const BlockDecl *blockDecl = blockInfo.getBlockDecl();
CurGD = GD;
+
+ CurEHLocation = blockInfo.getBlockExpr()->getLocEnd();
BlockInfo = &blockInfo;
--- /dev/null
+// RUN: %clang_cc1 -fcxx-exceptions -fexceptions -gline-tables-only -fblocks -emit-llvm %s -o - | FileCheck %s
+
+void fn();
+
+struct foo {
+ ~foo();
+};
+
+void func() {
+ ^{
+ foo f;
+ fn();
+ // CHECK: cleanup, !dbg [[LINE:![0-9]*]]
+ // CHECK: [[LINE]] = !{i32 [[@LINE+1]],
+ }();
+}