Reimplement destroy as an interface (#5678)

This changes `Destroy` to use an interface for its implementation.

Note that this change includes a lot of test updates. Even when
`Destroy` is a no-op, it still causes code generation as part of
determining that.

Originally I was trying to use ranges to cut down the scope of this, and
to a degree I think they have. But a flipside here is that cases where
no destructors should be generated -- particularly globals -- would be
needed to completely remove destructor calls. Even for ranges, the range
can often include the destructor placement. So I've shifted
frame-of-thought a little: accept a bunch of destructor churn, because
destructors are needed and will be prevalent. The verbosity is a feature
of the design to make desugaring apparent in IR, not a bug.
This commit is contained in:
Jon Ross-Perkins
2025-06-27 21:57:14 +00:00
committed by GitHub
parent bba037738d
commit 0722dab0ef
171 changed files with 11900 additions and 1434 deletions
@@ -81,6 +81,10 @@ fn M() {
// CHECK:STDOUT: %.loc54 = load double, ptr %p.var, align 8, !dbg !18
// CHECK:STDOUT: %G.call.loc54 = call double @_CG.Main.66be507887ceee78(double %.loc54), !dbg !19
// CHECK:STDOUT: store double %G.call.loc54, ptr %q.var, align 8, !dbg !20
// CHECK:STDOUT: %.loc49_3 = load double, ptr %q.var, align 8, !dbg !10
// CHECK:STDOUT: %.loc48_3 = load double, ptr %p.var, align 8, !dbg !9
// CHECK:STDOUT: %.loc47_3 = load i32, ptr %m.var, align 4, !dbg !8
// CHECK:STDOUT: %.loc46_3.2 = load i32, ptr %n.var, align 4, !dbg !7
// CHECK:STDOUT: ret void, !dbg !21
// CHECK:STDOUT: }
// CHECK:STDOUT: