Jon Ross-Perkins 0722dab0ef 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.

2025-06-27 21:57:14 +00:00

..

array_in_place.carbon

Reimplement destroy as an interface (#5678)

2025-06-27 21:57:14 +00:00

assign_return_value.carbon

Reimplement destroy as an interface (#5678)

2025-06-27 21:57:14 +00:00

base.carbon

Reimplement destroy as an interface (#5678)

2025-06-27 21:57:14 +00:00

field.carbon

Add min-preludes to most of lowering and a few more slow tests (#5680)

2025-06-17 20:43:31 +00:00

function_param.carbon

Use static allocas for temporaries. (#5734)

2025-06-25 21:53:39 +00:00