cyx-6 opened a new issue, #775: URL: https://github.com/apache/tvm-ffi/issues/775
Dear community: This is a call for vote to release apache-tvm-ffi version v0.1.14. The main highlights of this release are * Structural transformation APIs — `StructuralMutator` recursively transforms reflected object graphs, with `structural_map` providing a typed callback interface for compiler passes, alongside `maybe_inplace_mutate` and `var_remap`. This completes the structural family next to the existing equality, hashing, and walking APIs. C++ `StructuralMap` callbacks accept flexible return types: a replacement value, `Expected<T>`, `Error`/`Unexpected`, or a thrown `Error`, and match before recursive descent so unmatched nodes skip remap lookup and callback-chain work. * Opaque pointer handler map — third-party extension types that cannot define or accept monkey-patching of `__tvm_ffi_opaque_ptr__` can now participate in opaque-pointer conversion via `tvm_ffi.core._OPAQUE_PTR_HANDLERS`, without changing their owning package. * Stronger static typing through `Any` — static object type bounds are now propagated across `ObjectPtr`, `ObjectRef`, and raw-object conversions into `Any` and `AnyView`, while runtime validation for unconstrained values is unchanged. * Rust structural and object binding support — all four structural operations (walk, visit, map, mutate) gain typed callbacks and a `#[dispatch(...)]` frontend; the object binding runtime adds zero-copy upcasts, identity comparison, and reflection-table method lookup; and containers now hold heterogeneous `Any` elements. * Safer copy-on-write through `unique()` — `Object::unique()` now requires one strong reference *and* no external weak references, since a live `WeakObjectPtr` can still upgrade while a strong owner exists. `use_count()` keeps its strong-only semantics. * Free-threaded Python cross-builds — Python discovery now separates the host interpreter running Cython from the target development artifacts, unblocking 3.14t wheel builds on cross-compiled platforms such as Linux PPC64LE and macOS ARM64. * Rust stubgen backend — `tvm-ffi-stubgen --target rust` generates opaque Rust bindings for every reflected object: a `#[repr(C)]` struct embedding only its parent, upcasts along the ancestor chain, and one accessor per reflected field reading through the C ABI getter, so object bytes are never reproduced. * Callback-driven traversal primitives — `StructuralVisit` and `StructuralMutate` expose lower-level engines where the callback owns descent and traversal order, for context-carrying passes that `StructuralWalk` cannot express. * Performance and platform fixes — hot-path inlining across `ObjectPtr`, `Optional`, and `Any`, a leaner structural-mutation engine, and Windows backtraces are now serialized around DbgHelp so a concurrent trace no longer kills the process before the original error prints. * Correctness fixes — Python annotation metadata is stabilized across versions, and `ffi.Error` is now picklable so FFI-originated exceptions survive round-tripping. * Def-region terminology renamed in the C ABI — `kTVMFFIDefRegionKindRecursive`/`NonRecursive` become `Pattern`/`Simple`, and the matching `kTVMFFIFieldFlagBitMaskSEqHashDef*` flags follow. Every enum value keeps its number, so binaries stay compatible, but source naming these constants needs the new spellings. A new `kTVMFFIUnchanged` marker is also added for structural mutation. Link to draft release notes: https://github.com/apache/tvm-ffi/releases/tag/v0.1.14-rc5 Link to release candidate: https://dist.apache.org/repos/dist/dev/tvm/tvm-ffi-v0.1.14-rc5/ Everyone is welcomed to vote. Please vote by replying to this thread explicitly. The vote will last at least 72 hours, please vote +1 = approve +0 = no opinion -1 = disapprove (provide reason) NOTE: this thread is being mirrored in dev@ -- 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]
