Skip to content

Fix cross-module generic type alias export and add coverage#287

Merged
ASDAlexander77 merged 2 commits into
mainfrom
fix/generic-type-alias-cross-module-export
Jul 23, 2026
Merged

Fix cross-module generic type alias export and add coverage#287
ASDAlexander77 merged 2 commits into
mainfrom
fix/generic-type-alias-cross-module-export

Conversation

@ASDAlexander77

Copy link
Copy Markdown
Owner

Summary

  • Last remaining item from decls-cross-module-declaration-mechanism's unverified list (after generic classes/Fix cross-module generic class export/import (4 co-operating bugs) #280, generic functions/Fix cross-module generic function export and add coverage #285, generic interfaces/Fix cross-module generic interface export and add coverage #286): genericTypeAliasMap's registration path in mlirGen(TypeAliasDeclaration) never called any export function for the generic branch - only the non-generic else-branch calls addTypeDeclarationToExport. Confirmed with a cross-module repro: a generic type alias failed cross-module resolution under -shared.
  • Unlike the other three generic declaration kinds, there is no dedicated GenericTypeAliasInfo struct tracking sourceFile/elementNamespace for a generic type alias - genericTypeAliasMap's value is just {typeParams, typeNode}, since resolution (getTypeByTypeReference / resolveGenericTypeInNamespace) is pure compile-time type substitution on the stored TypeNode, never re-invoking mlirGen on the whole declaration the way a class/function/interface instantiation does. So instead of adding a new Info struct, addGenericTypeAliasDeclarationToExport takes the AST node and namespace directly and is called inline from the one registration site, gated on stage == Stages::SourceGeneration (a given top-level TypeAliasDeclaration is visited exactly once per stage, so this is sufficient dedup - no "already registered" early-return branch exists here to retry from, unlike the class/function/interface fixes).
  • Tested with both a single- and two-type-param alias (Box<T>, Pair<A,B>) to check for the classes/functions' export-bleed-on-instantiation bug; neither triggered it, matching generic interfaces' outcome - a type alias has no compiled body or runtime entity at all, so there's nothing for an instantiation to wrongly dllexport in the first place. All 3 tiers passed on the first attempt - the simplest of the four generic-declaration-kind fixes.
  • This closes out the generic cross-module export arc: classes (4 bugs) → functions (2 bugs) → interfaces (1 bug) → type aliases (1 bug, first try).

Test plan

  • New export_type_alias_generic.ts / import_type_alias_generic.ts cross-module pair (single- and two-type-param generic type aliases), 3 tiers: test-compile-export-import-type-alias-generic, test-compile-shared-export-import-type-alias-generic, test-jit-shared-export-import-type-alias-generic
  • Full suite: ctest -C Debug -j8 — 802/802 green (799 previously green + 3 new)

🤖 Generated with Claude Code

ASDAlexander77 and others added 2 commits July 23, 2026 09:14
Last remaining item from decls-cross-module-declaration-mechanism.md's
unverified list (after generic classes/PR #280, generic functions/PR
#285, generic interfaces/PR #286): genericTypeAliasMap's registration
path in mlirGen(TypeAliasDeclaration) never called any export function
for the generic branch - only the non-generic else-branch calls
addTypeDeclarationToExport. Confirmed with a cross-module repro: a
generic type alias failed cross-module resolution under -shared.

Unlike the other three generic declaration kinds, there is no
dedicated GenericTypeAliasInfo struct tracking sourceFile/
elementNamespace for a generic type alias - genericTypeAliasMap's
value is just {typeParams, typeNode}, since resolution
(getTypeByTypeReference / resolveGenericTypeInNamespace) is pure
compile-time type substitution on the stored TypeNode, never
re-invoking mlirGen on the whole declaration the way a class/function/
interface instantiation does. So instead of adding a new Info struct,
addGenericTypeAliasDeclarationToExport takes the AST node and
namespace directly and is called inline from the one registration
site, gated on `stage == Stages::SourceGeneration` (a given top-level
TypeAliasDeclaration is visited exactly once per stage, so this is
sufficient dedup - no "already registered" early-return branch exists
here to retry from, unlike the class/function/interface fixes).

Tested with both a single- and two-type-param alias (Box<T>,
Pair<A,B>) to check for the classes/functions' export-bleed-on-
instantiation bug; neither triggered it, matching generic interfaces'
outcome - a type alias has no compiled body or runtime entity at all,
so there's nothing for an instantiation to wrongly dllexport in the
first place. All 3 tiers passed on the first attempt, no follow-up fix
needed - the simplest of the four generic-declaration-kind fixes.

New export_type_alias_generic.ts/import_type_alias_generic.ts
cross-module test pair (compile, -shared compile, -jit -shared tiers).
802/802 green. This closes out the generic cross-module export arc.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Resolves conflict with #285 (generic function export fix, merged in
the meantime): both PRs added a new add_test entry for their
respective generic-declaration-kind test pair at the same anchor
lines in CMakeLists.txt. Kept both sets of entries side by side.
MLIRGenImpl.h auto-merged cleanly - the two addGenericXDeclarationToExport
functions (function/type-alias) sit at different insertion points.

Full suite re-verified after merge: 805/805 green.
@ASDAlexander77

Copy link
Copy Markdown
Owner Author

Rebased/merged origin/main to resolve the conflict (commit f17792d) - full suite re-verified at 805/805 green.

@ASDAlexander77
ASDAlexander77 merged commit fa5038f into main Jul 23, 2026
2 checks passed
@ASDAlexander77
ASDAlexander77 deleted the fix/generic-type-alias-cross-module-export branch July 23, 2026 09:02
ASDAlexander77 added a commit that referenced this pull request Jul 23, 2026
Resolves conflicts with #285 (generic functions) and #287 (generic
type aliases), both merged in the meantime: all three PRs added a new
addGenericXDeclarationToExport function at the same insertion point in
MLIRGenImpl.h, and a matching add_test entry at the same anchor lines
in CMakeLists.txt. Kept all four functions
(class/function/interface/type-alias) and all test entries side by
side.

Full suite re-verified after merge: 808/808 green.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant