Repository navigation
import: a module's file for the target, <name>.<os>.ts, before <name>.ts - #552
Merged
Merged
Conversation
An import without an extension resolves to <name>.win32.ts on Windows, <name>.linux.ts on Linux and Android (<name>.<the triple's OS name>.ts elsewhere) when that file exists, else to <name>.ts. A module with code per target - a C++ ABI's vtables and struct layouts, for @cppvtable classes - is then picked as the default library picks lib.win32.ts or lib.linux.ts, while the importer names one module. Tests: import_os_suffix.ts with export_os_suffix.win32.ts / .linux.ts, compiled and run on the host; and the import's declarations checked for each target triple (--emit=mlir), on any host. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
An import with no extension now resolves to the target's own file first:
import "./m"resolves to (if it exists)m.win32.tsm.linux.tsm.<the triple's OS name>.tsIf that file doesn't exist, the import resolves to
m.tsas before.The names follow the default library, which builds
lib.win32.tsorlib.linux.ts, usinglib.linux.tsfor Android.Why: some modules need a different declaration per target, not just different function bodies. The motivating case is native_ts_graphics' NVRHI bindings,
@cppvtableclasses whose slot numbers and struct layouts follow the C++ ABI. MSVC has one destructor slot and Itanium has two, overloads are ordered differently, andstd::stringhas a different layout in each C++ standard library.A slot number is fixed where the call is compiled, so the default library's approach (one
.d.ts, with the implementation picked at link time) can't switch these. With this change the importer names one module,import { nvrhi } from "../core/nvrhi", and the build compiles and linkscore/nvrhi.win32.tsorcore/nvrhi.linux.tsbeside it.Change
includeFilePath(MLIRGenImpl.h) checks for the target's file first.targetOSFileSuffixmaps the target triple towin32,linux, or the triple's OS name.Tests
test-compile-export-import-os-suffix:import_os_suffix.tsimports./export_os_suffix, and there is noexport_os_suffix.ts. It is compiled and run with the host's file:export_os_suffix.win32.tscallsGetCurrentProcessId;export_os_suffix.linux.tscallsgetpid.test-compile-import-os-suffix-win32/-linux: run on any host with--emit=mlir -mtriple=.... Each checks that the import picked up that target's OS function and not the other one.🤖 Generated with Claude Code