Docs: generated code requires a zerodds-sql-filter dependency that is never stated, so a consumer following the crate documentation gets dozens of E0433 errors

[swarm59]

Docs: generated code requires a zerodds-sql-filter dependency that is never stated, so a consumer following the crate documentation gets dozens of E0433 errors

Crate: zerodds-idl-rust
Version: 1.0.0-rc.6 (source clone at commit b0033675f5, 2026-07-23)
Type: documentation defect, not a code defect

Summary

Code emitted by generate_rust_module in its default (DDS) mode references four crates:

• zerodds_cdr
• zerodds_dcps
• zerodds_types
• zerodds_sql_filter

The crate's own documentation does not state this dependency set. lib.rs says the generator emits

pub struct ... plus impl zerodds_dcps::DdsType for ... plus the necessary zerodds_cdr::CdrEncode/CdrDecode helpers

which names two of the four, and zerodds-sql-filter is not a dependency of zerodds-idl-rust itself, so it does not appear in its manifest either. Nothing a consumer reads tells them it is needed.

A consumer who declares the documented dependencies gets, for even the most trivial input, 38 instances of

error[E0433]: cannot find module or crate `zerodds_sql_filter` in this scope

Reproduction

struct S { long a; };

Codegen succeeds (112 lines). Distinct zerodds_* paths in the output:

["zerodds_cdr", "zerodds_dcps", "zerodds_sql_filter", "zerodds_types"]

Compiling that output against zerodds-dcps, zerodds-cdr and zerodds-types only:

error[E0433]: cannot find module or crate `zerodds_sql_filter` in this scope
   --> src\lib.rs:174:63
    |
174 | "seconds" => ::core::option::Option::Some(zerodds_sql_filter::Value::Int(self.seconds as ...

Adding zerodds-sql-filter clears all of them.

Where it comes from

crates/idl-rust/src/struct_emit.rs:569-577 emits, as part of the DdsType impl:

fn field_value(&self, path: &str) -> ::core::option::Option<zerodds_sql_filter::Value>

so the dependency is inherent to the DDS-mode output, not incidental.

Note on cdr_only

RustGenOptions::cdr_only does remove it — its doc comment says it "omits the DdsType impl (XCDR2 + field_value) that pulls in zerodds_dcps/zerodds_types/zerodds_sql_filter". That is the clearest statement of the dependency set we found anywhere, but it is on the option that turns the DDS path off: cdr_only is described as the CORBA/GIOP path and leaves only classic CdrEncode/CdrDecode. It is therefore not usable by someone generating DDS data types, and a reader looking for "what do I need to depend on" is unlikely to find it there.

Impact

Low severity, high friction: the first-run experience for a new consumer is a wall of errors with no indication of the cause, on input as simple as a one-field struct. Once known, it is a one-line fix in Cargo.toml.

Suggested fix

State the required dependency set for generated code in the crate-level documentation and README — ideally as a copy-pasteable [dependencies] block for each mode:

• default (DDS): zerodds-dcps, zerodds-cdr, zerodds-types, zerodds-sql-filter
• cdr_only: zerodds-cdr

A note in the generate_rust_module doc comment would catch most readers, since that is the entry point they arrive at.

[SandraK82]

Thank you again, @swarm59, for another precise report and for testing the generated output as a real consumer project. You were right about the resulting E0433 errors, although the underlying problem turned out to be a code-generation dependency leak rather than only missing documentation.

Every generated Rust struct emitted references to zerodds_sql_filter::Value, even when the consumer did not use content filtering. That forced applications to declare an implementation-detail crate as a direct dependency. The existing zerodds-dcps API already re-exported the type as FilterValue, but the IDL backend did not use that public path.

The direct issue is fixed on main in bd7e592. Generated Rust code now uses zerodds_dcps::FilterValue, so normal generated projects need only the documented public ZeroDDS dependencies. The generated fixtures, snapshots, documentation, and consumer dependency checks were updated accordingly.

Your report also led us to audit dependency and import hygiene across all 17 code-generation backends.

That audit confirmed that the SQL-filter dependency leak itself was Rust-specific, but it uncovered related problems elsewhere:

• TypeScript unconditionally imported MD5 and RPC descriptor symbols into every generated file, even when the IDL contained neither keyed types nor interfaces.
• Enabling a real noUnusedLocals TypeScript compile gate found additional unconditional type imports and an unused generated type-guard variable that the previous test configuration had not actually detected.
• Ada unconditionally emitted Ada.Containers.Vectors and Ordered_Maps dependencies and speculative vector instantiations. The deeper pass also found a real compile blocker for an array of sequence<Struct>, where the required vector package was referenced without being instantiated.

Those imports and generated dependencies are now driven by the features actually used by the IDL. TypeScript is checked with a real strict tsc configuration including noUnusedLocals, and the Ada generator has dedicated regressions for the conditional container and array-of-sequence paths. The remaining backends were reviewed and were either already conditional or self-contained by construction.

The complete public main build is green:
https://github.com/zero-objects/zero-dds/actions/runs/30556000574

I am closing this discussion as fixed. If a generated consumer still requires an undocumented direct dependency, or if a backend emits imports for features that are not present in the IDL, please let us know here — we will be very happy to reopen the discussion and extend the dependency-hygiene audit.

Your continued careful testing is helping us improve not only the Rust consumer experience, but the generated dependency and import discipline across the full backend set.