DL→Rust codegen: a @key member whose type is a typedef alias of a primitive is rejected as a "complex key", so any IDL using aliased key types cannot be generated

[swarm59]

IDL→Rust codegen: a @key member whose type is a typedef alias of a primitive is rejected as a "complex key", so any IDL using aliased key types cannot be generated

Crate: zerodds-idl-rust
Version: 1.0.0-rc.6 (source clone at commit b0033675f5, 2026-07-23)
Component: key-holder emission (struct_emit.rs)

Type and module names in the reproducers below are illustrative reduced cases, not real-world names.

Summary

generate_rust_module fails with

Unsupported { what: "complex @key field (enum or unresolved nested type)", at: 0 }

for any struct whose @key member is typed with a typedef alias, even when that alias resolves to a plain integer.

Aliasing key types is a common IDL idiom (typedef unsigned long long ItemId; … @key ItemId item_id;). Where an IDL set uses it consistently for its key types, the majority of files become ungeneratable.

The same alias on a non-key member generates correctly, so this is specific to the key path rather than to typedef handling in general.

Root cause

crates/idl-rust/src/struct_emit.rs:956-961, in the key-field emission path:

// Not a resolvable struct (enum / unresolved scoped) — leave the
// complex-key error so the gap is explicit, not silently wrong.
return Err(RustGenError::Unsupported {
    what: "complex @key field (enum or unresolved nested type)",
    at: 0,
});

When the member's TypeSpec is a Scoped name, the emitter attempts to resolve it to a struct (for nested-key composition). If it is not a struct it gives up. A typedef alias of a primitive is never considered, although the information needed to resolve it is present in the same AST.

We note and appreciate that the failure is explicit rather than silently wrong — the comment above says as much. The gap is only that alias resolution is missing, not that the guard is wrong.

Reproduction

Three cases, run through zerodds_idl::parse + generate_rust_module with ParserConfig::default() and RustGenOptions::default():

// (1) FAILS
typedef unsigned long long ItemId;
struct Item { @key ItemId item_id; };

CODEGEN FAIL: Unsupported { what: "complex @key field (enum or unresolved nested type)", at: 0 }

// (2) control — primitive key inline: OK
struct Item { @key unsigned long long item_id; };

CODEGEN OK (118 lines)

// (3) control — same alias, not a key: OK
typedef unsigned long long ItemId;
struct Item { ItemId item_id; };

CODEGEN OK (113 lines)

Case (3) isolates the defect to the key path.

An enum-typed @key fails identically (enum E { E_A, E_B }; struct D { @key E e; };). We have no enum keys ourselves, so we cannot say whether that case is intended to be supported; it is mentioned only because it shares the error site.

Impact

Any IDL that uses an aliased key type cannot be generated at all. There is no partial output — the whole module fails. In our own IDL set this affects most files and the majority of types.

Alternatives checked before filing

#	Alternative	Finding
1	A RustGenOptions flag relaxing key handling	RustGenOptions has two fields only: header_comment and cdr_only. cdr_only omits the entire DdsType impl (the CORBA/GIOP path), so it does not apply to a DDS data type.
2	Declaring the key with the primitive inline	Would mean changing an IDL baseline to accommodate a tool limitation, altering a published type contract. Rejected.
3	A pre-pass on the AST before codegen	Works — see below — but is a downstream workaround, not a fix.

Workaround we are using

An AST pre-pass that collects typedef aliases of primitives and rewrites @key members typed with such an alias to the underlying primitive before calling generate_rust_module. Roughly 150 lines. It touches key members only, so non-key field types are unchanged, and it refuses to rewrite where one simple name maps to two different bases rather than guessing.

With it, every file in our set generates.

Suggested fix

In the key-field emission path, before returning Unsupported, resolve the scoped name against the typedef declarations already present in the AST, and where it resolves (transitively) to a primitive, emit the key-holder write for that primitive — the same code path case (2) already takes.

We have not attempted a patch against the real codebase; we would rather keep testing the unmodified published artefact. Happy to supply the pre-pass and the reduced reproducer project if useful.

[sueun-dev]

The key-field emitter never dealiases typedefs. In emit_key_field_write (struct_emit.rs) a TypeSpec::Scoped @key is only resolved through struct_def_by_scoped for the nested-struct case; a typedef alias isn't a struct, so it falls to the complex @key field catch-all even when it resolves to a plain int. That's why the same alias on a non-key member is fine, only the key path takes that branch.

Workaround until it's fixed: type the @key field with the underlying primitive directly (@key unsigned long long item_id;) and keep the typedef for the non-key fields. Still repros on current main (572c071).

[SandraK82]

Thank you, @swarm59, for the precise report and minimal reproducer, and thank you, @sueun-dev, for tracing it to the exact KeyHolder branch and documenting a useful workaround. You were both right: the Rust key path followed a scoped type only when it resolved to a struct, so a typedef ending in a primitive fell through to the generic “complex key” error.

This is fixed on main in bd7e592. Key fields are now dealiased before KeyHolder sizing and emission, with regression coverage for primitive, string, chained-alias, and nested-struct cases.

Your report also gave us the entry point for a much broader KeyHash audit. We found and fixed related cases beyond the original Rust failure: C# could silently omit typedef-aliased or nested-struct key material; C++, Java, and TypeScript could use the full nested struct instead of its key subset or apply inconsistent member ordering; array declarators and typedef indirection exposed further over- and under-inclusion paths; and the corresponding thin-backend paths were checked and corrected where necessary. These cases are now covered by cross-backend KeyHash and generated-code tests rather than only the original reproducer.

One independently scoped limitation remains under active work: member-id ordering under struct-level @autoid(HASH) in several non-Rust key paths. It is not the typedef-resolution failure reported here, and we are tracking it separately rather than hiding it behind this closure.

The complete public main build, including the broader regression set, is green: https://github.com/zero-objects/zero-dds/actions/runs/30556000574

I am closing this discussion as fixed. If you still encounter the original failure on current main, or find another KeyHash shape that disagrees across backends, please let us know here — we will be very happy to reopen the discussion and investigate further.

Thank you again for helping us improve considerably more than the single path in the original report.