[ASDAlexander77]

Merge order: don't merge this PR until a tslang release with these is deployed:

• @cppvtable: methods returning a record through MSVC's hidden pointer TypeScriptCompiler#551, then #553 (stacked on it);
• import: a module's file for the target, <name>.<os>.ts, before <name>.ts TypeScriptCompiler#552 (independent).

Under pre-alpha94, import "./nvrhi_abi" finds no file, and every example that imports core/nvrhi stops compiling.

Summary

core/nvrhi.ts (NVRHI's interfaces called directly through @cppvtable classes) now works under two C++ ABIs: MSVC x64 on Windows, and Android's Itanium ABI (clang + libc++) on x86-64 and AArch64. I split it the way tslang's default library splits lib.ts and lib.<os>.ts:

Module	Holds
core/nvrhi_types.ts	structs and constants that every ABI lays out the same way
core/nvrhi_abi.win32.ts	@cppvtable classes with MSVC's slots; the release CRT's std::string and the structs that hold one; helpers that depend on them
core/nvrhi_abi.linux.ts	the same for Android's Itanium ABI and libc++
core/nvrhi.ts	the functions; its import "./nvrhi_abi" picks the target's file (#552)

Examples still import { nvrhi } from "../core/nvrhi". CMake's NVRHI_TS_SOURCES lists the three modules for the target.

What differs between the ABIs

• Destructor slots: MSVC has 1, Itanium has 2 (complete and deleting). Every slot after them is shifted by one. Overloads happen to keep MSVC's order.
• std::string: 32 bytes in the release CRT, 24 in libc++. That makes BufferDesc 72 bytes against 80, and TextureDesc 104 against 112.
  • libc++'s short form is a first byte of size × 2, then up to 22 characters.
  • stdString(), stdStringSize() and sameShortStdString() are written once per ABI.
• Structs returned by value: now declared as tuples (RefCountPtr, marked @cppnontrivial, and NativeObject), with no explicit hidden-pointer parameter.
  • tslang passes the hidden pointer where each ABI expects it (#551, #553): after this for MSVC, before this as sret for Itanium. On Itanium the 8-byte NativeObject comes back in a register.
  • Itanium has no workaround for the old explicit-parameter form, because its hidden pointer goes before this.
• Structs passed by value: clearTextureFloat's 16-byte TextureSubresourceSet is the only one.
  • MSVC passes a pointer to a copy; Itanium passes two 64-bit registers.
  • The Linux declaration takes two u64s, and the clearTextureFloat helper moved into the ABI files.
  • I first got this wrong, and it crashed inside NVRHI on Android.

Other changes

• Donut_CanCallNvrhiDirectly(): now also returns 1 on Android with libc++, x86-64 or AArch64. layoutMatches() still compares the struct sizes at run time.
• tools/check_nvrhi_slots.py --abi itanium: checks nvrhi_abi.linux.ts against NDK clang's -fdump-vtable-layouts for both x86_64-linux-android29 and aarch64-linux-android29. Both ABIs match; swapping two slots makes it report both.
• nvrhi_direct: builds on every platform (donut_compile_shaders_all_platforms) and runs through adb shell on Android. It now asks Vulkan for a compute queue only if the device has one.
• NVRHI bug (not fixed here): Vulkan getNativeQueue dereferences m_Queues[queue] without a null check, and the emulator's device has no compute queue. nvrhi_direct now avoids asking for it.
• tslang finding: << on a u64 keeps JavaScript's 32-bit semantics (<u64>3 << 33 is 6). The Linux packing multiplies instead.
• README: "Calling NVRHI directly" updated.

Testing

All runs below used a local tslang built from TypeScriptCompiler #551, #552 and #553:

Platform	Result
Windows, CTest with -debug	headless.dx12/.vk, headless.donut.dx12/.vk and nvrhi_direct.dx12/.vk pass (6/6)
Windows, JIT (run_jit.bat-style)	headless and nvrhi_direct pass on D3D12 and Vulkan
Android x86_64 emulator (API 34, -gpu host, Vulkan on the RTX 5080)	headless -vk takes the direct path and passes, and so does headless -vk -donut. nvrhi_direct -vk passes every check: native objects, ref counts, buffers, debug names, compute, barriers, texture clear and readback
Android arm64-v8a	builds and links; not run, since there's no arm64 device here. nvrhi.createBuffer's call puts the result pointer in X8 and goes through slot 20

Not covered:

• -debug on the emulator, which has no Vulkan validation layer.
• The software-Vulkan emulator (SwiftShader) can't create the device at all, with or without this change.

🤖 Generated with Claude Code