mvanhorn opened a new pull request, #606: URL: https://github.com/apache/tvm-ffi/pull/606
## Summary The non-throwing contract for `TVMFFIObject::deleter` is now stated explicitly, and the deleter is invoked through a `noexcept` boundary so a contract violation terminates deterministically instead of leaking the rest of a container. ## Why this matters Issue [#457](https://github.com/apache/tvm-ffi/issues/457) noted that the destructors of `SeqBaseObj`, `SmallMapObj`, and `DenseMapObj` call `Any::~Any()` in plain loops, so a throwing deleter would leak the remaining elements and the backing buffer. Maintainer tqchen declined per-loop try/catch, since a destructor-thrown exception is already undefined behavior and the deleter is a C function pointer whose contract is implicitly `noexcept`; both tqchen and junrushao converged on making that contract explicit and fail-fast rather than guarding each loop. This change implements that converged scope and leaves the container destructor loops untouched. ## Testing `include/tvm/ffi/c_api.h` documents on the `deleter` field that it MUST NOT throw. In `include/tvm/ffi/object.h`, a new `noexcept` `Object::CallDeleter` centralizes every deleter invocation, and `DecRef`, `DecWeakRef`, and `ObjectUnsafe::DecRefObjectHandle` are marked `noexcept` so a throwing deleter terminates at the boundary. `tests/cpp/test_object.cc` adds a `static_assert` that the decref path stays `noexcept` and a death test (`ThrowingDeleterTerminates`, gated on `GTEST_HAS_DEATH_TEST`) confirming a throwing deleter terminates. Covered by the new tests in this PR; full suite runs in CI. Fixes #457 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
