Use a new macro trick to avoid throwing in destructors.

[alexreinking]

As discovered in #8767, throwing in destructors is a bad idea. We can avoid doing this in our error handling macros using a nifty for-loop trick in the macro.

---

The trick appears here:

#define _halide_internal_diagnostic(condition, type, condition_string)  \
    /* NOLINTNEXTLINE(bugprone-macro-parentheses) */ \
    if (!(condition)) for (type _err; _err; _err.issue()) _err.init(__FILE__, __FUNCTION__, __LINE__, condition_string)

The bare if and for statements guard _err.init(...), which returns itself for the sake of << chaining. The if condition prevents evaluation, the for loop issues the warning or error at the end of "each" iteration. In reality, there is only one iteration in any case: for errors, issue() is marked [[noreturn]] and for warnings, the operator bool returns false after issue() has been called.

[alexreinking]

Looks like I broke correctness_custom_error_reporter.

[mcourteaux]

adams2019_test_apps_autoscheduler failing is new. That's not the case on any of the previous builds, AFAI can remember.

[alexreinking]

adams2019_test_apps_autoscheduler failing is new. That's not the case on any of the previous builds, AFAI can remember.

Hmm, that's a TIMEOUT flake. I ran it manually and it took something like 18 minutes to complete, but it did pass. I don't know how this PR could be responsible for that. It runs in 90 on my MacBook, which is about how long it always took.

Also it's on the ASAN branch, so being slow is no surprise.

It timed-out in this PR too: #8700

[alexreinking]

A fun blog post from JeanHeyd Meneide on the defer TS for C2y and the destructor issue we're observing:

There are also some edge cases where defer is actually better than C++, as mentioned in the rationale of the proposal. For example, exceptions butt up against the very strict noexcept rule for destructors (especially since its not just a rule, but required for standard library objects). This means that using RAII to model defer becomes painful when you intentionally want to use defer⸺or scope_guard⸺as an exception-detection mechanism and a transactional rollback feature.

https://thephd.dev/c2y-the-defer-technical-specification-its-time-go-go-go#there-are-also-some-edge-cases-where-defer-is-actually-better-th

[mcourteaux]

Got two questions, and one suggestion for a comment to clarify something. Otherwise LGTM.

[mcourteaux]

The method finalize_message() set issued to true? The method issue() doesn't? This is confusing. Is there better naming possible? Looking around, I can tell now that issue() calls finalize_message(), and you want to assure that this boolean-setting step is always done for all the inheriting classes. Not sure how I would improve this. Perhaps just add a comment in finalize_message() that says:

Sets issued because every finalize_message() is called by all inheriting issue(). See the nifty for-loop trick at the _halide_internal_diagnostic macro below.

[alexreinking]

If issue did, it happen in two places 🫠

[mcourteaux]

If this file is gone from the autoschedulers, then where do the error/warning macros come from? Are they exposed in Halide.h? I thought they weren't?

[alexreinking]

They are if you define HALIDE_KEEP_MACROS, which happens in HalidePlugin.h

[alexreinking]

Failures are unrelated