[FEAT][RUST] Add AnyCompatible::to_any. (#712)

## Summary

Add `AnyCompatible::to_any(&self) -> Any`, the by-reference counterpart
of `Any::from(value)`.

`From<AnyView> for Any` now dispatches inline instead of always calling
`TVMFFIAnyViewToOwnedAny`: an object increfs, a self-contained cell is a
bitwise copy, and only the three borrowed forms Rust never produces
(`kTVMFFIRawStr`, `kTVMFFIByteArrayPtr`, `kTVMFFIObjectRValueRef`) still
go to the runtime, behind `#[cold] #[inline(never)]`. This mirrors C++
`details::InplaceConvertAnyViewToAny`. `is_plain_inline` moves from
`extra::structural_common` into `any.rs`.

## Motivation

`Any::from` takes ownership. A value reachable only through a shared
reference — a field behind a `Deref` into object storage, e.g. `node.a`
on a `&AddObj` — cannot be moved out, so every such site has to write
`Any::from(node.a.clone())` today.

`impl From<&T> for Any` cannot be added instead: `&` is fundamental, so
a downstream crate may implement `AnyCompatible` for its own `&T` and
the two impls overlap (E0119). A provided trait method has no such
conflict, and every `AnyCompatible` type — including `Option<T>` and the
containers — picks it up for free.

## Usage

```rust
fn first_operand(node: &AddObj) -> Any {
    node.a.to_any() // was: Any::from(node.a.clone())
}
```

`to_any()` leaves the borrowed value usable and retains object-backed
values by increfing them.

## Efficiency and Test

`to_any` costs whatever `From<AnyView> for Any` costs, which no longer
crosses the C ABI on every conversion. Where the type index is a
compile-time constant (`i64`, `Array`, `Map`) the dispatch folds away
and `to_any` matches `Any::from`. For `String`/`Bytes` and derived
object refs the index is read at runtime, so the normalizing branch
survives and the caller keeps a stack frame. That is deliberate: a type
whose view is a borrowed representation — the Rust counterpart of C++
`RValueRef<T>` — needs that branch to stay.

The result is on par with `Any::from`: neither emits a call or an unwind
path, and on the object path both do the same single `lock incq`.
Verified on the release asm (x86-64, `-C codegen-units=1`).

Tests in `tests/test_any.rs`: `to_any` matches `Any::from` across the
scalar, small-string/bytes, and object representations and increfs
exactly once (given back on drop); and it works on fields reached
through `Deref` — `String`, `Option<String>`, `i64` — where `Any::from`
does not compile.

Docs: new "Converting Borrowed Values into `Any`" section in
`docs/guides/rust_lang_guide.md`.

---------

Signed-off-by: yuchuan <yuchuan.7streams@gmail.com>
6 files changed
tree: 0b44f563809b5ed572ff721dc2ebf05af91eab50
  1. .agents/
  2. .claude/
  3. .github/
  4. 3rdparty/
  5. addons/
  6. cmake/
  7. docs/
  8. examples/
  9. include/
  10. licenses/
  11. python/
  12. rust/
  13. src/
  14. tests/
  15. .asf.yaml
  16. .clang-format
  17. .clang-tidy
  18. .cmake-format.json
  19. .gitignore
  20. .gitmodules
  21. .markdownlint-cli2.yaml
  22. .pre-commit-config.yaml
  23. .yamllint.yaml
  24. AGENTS.md
  25. CLAUDE.md
  26. CMakeLists.txt
  27. CONTRIBUTING.md
  28. KEYS
  29. LICENSE
  30. NOTICE
  31. pyproject.toml
  32. README.md
README.md

TVM FFI: Open ABI and FFI for Machine Learning Systems

📚 Documentation | 🚀 Quickstart

Apache TVM FFI is an open ABI and FFI for machine learning systems. It is a minimal, framework-agnostic, yet flexible open convention with the following systems in mind:

  • Kernel libraries - ship one wheel to support multiple frameworks, Python versions, and different languages. [FlashInfer]
  • Kernel DSLs - reusable open ABI for JIT and AOT kernel exposure frameworks and runtimes. [TileLang][cuteDSL]
  • Frameworks and runtimes - a uniform extension point for ABI-compliant libraries and DSLs. [PyTorch][JAX][PaddlePaddle][NumPy/CuPy]
  • ML infrastructure - out-of-box bindings and interop across languages. [Python][C++][Rust][XGrammar]
  • Coding agents - a unified mechanism for shipping generated code in production.

Features

  • Stable, minimal C ABI designed for kernels, DSLs, and runtime extensibility.
  • Zero-copy interop across PyTorch, JAX, and CuPy using DLPack protocol.
  • Compact value and call convention covering common data types for ultra low-overhead ML applications.
  • Multi-language support out of the box: Python, C++, and Rust (with a path towards more languages).

These enable broad interoperability across frameworks, libraries, DSLs, and agents; the ability to ship one wheel for multiple frameworks and Python versions (including free-threaded Python); and consistent infrastructure across environments.

Getting Started

Install TVM-FFI with pip, uv or from source:

pip install apache-tvm-ffi
pip install torch-c-dlpack-ext  # compatibility package for torch <= 2.9

Status and Release Versioning

C ABI stability is our top priority.

Status: RFC Main features are complete and ABI stable. We recognize potential needs for evolution to ensure it works best for the machine learning systems community, and would like to work together with the community for such evolution. We plan to stay in the RFC stage for three months from the v0.1.0 release.

Releases during the RFC stage will be 0.X.Y, where bumps in X indicate C ABI-breaking changes and Y indicates other changes. We anticipate the RFC stage will last for three months, then we will start following Semantic Versioning (major.minor.patch) going forward.

Documentation

Our documentation site includes:

Get Started

Guides

Concepts

Packaging

Developer Manual