Module interface_rust 

An IDL interface, as a complete DDS-RPC 1.0 Rust binding: the request and reply topic types of §7.5.1.1, a typed client and service trait, and a dispatcher — all runnable, not only declared.

adapter::interface reads the interface; emit::interface_cpp and emit::interface_java write declarations a peer’s own runtime gives a body to. This writes both halves: the topic types get a real XCDR2 codec, hand-assembled with the same per-field writers crate::encode::rust_codec uses for an ordinary struct, and the client and the dispatcher are built over zerodds_rpc::requester and zerodds_rpc::replier — the crate this generated file has to depend on, named in the preamble every generated interface carries.

Why the topic types get a codec here and nowhere else

C++, Java and TypeScript declare Calculator_add_In and stop: the octets are a job for a type-support pass none of the three has written (emit::interface_cpp’s own module doc says so). Rust’s generated client and service actually run — crates/rpc/tests/ sends a request and reads a reply — and a Requester<TIn, TOut> needs TIn: DdsType. So this crosses the boundary zerodds-rpc → zerodds-dcps → zerodds-lang-rules warns about, deliberately: not by making this crate depend on zerodds-rpc — it still does not — but by writing Rust source that does, exactly as crates/zerodds-build/src/dds_type.rs writes an impl zerodds_dcps::DdsType for a type this crate declared.

The wire layout

DDS-RPC 1.0 §7.5.1.1’s Basic Service Mapping: one request topic type and one reply topic type per interface, each a header plus a data union over every operation. crates/rpc/src/codegen.rs is the data model this shape comes from; this crate cannot depend on it (zerodds-rpc depends on zerodds-dcps depends on this crate), so the shape is read off adapter::interface::Service directly, the way emit::interface_cpp already does for C++.

A union becomes a Rust enum, one variant per case plus a default UnknownOp(u8) — §7.5.1.1.6 rule 3 and §7.5.1.1.7 rule 3 — and its encode/decode write the long discriminator interface::operation_hash/interface::exception_hash compute, then delegate to the case payload’s own codec. Every payload type — an _In, an _Out, a _Result, a raised exception — gets exactly that: an inherent encode(&self, w: &mut Writer) and decode(r: &mut Reader), member by member, through crate::encode::write_value_to and crate::encode::read_for — the same two functions crate::encode::rust_codec calls for a declared struct.

Every synthesized type is @final: no DHEADER, matching crates/rpc/src/common_types.rs’s own choice for RequestHeader and ReplyHeader, and matching the classic-CDR shape DDS-RPC 1.0 predates XTypes 1.3’s extensibility kinds with. The encoding is fixed to XCDR2 little-endian regardless of the file’s own --encoding/--endian — rpc_layout_key — because zerodds_rpc::requester::Requester::send_request_blocking calls TIn::encode, the DdsType bridge’s un-suffixed method, which is always that one cell.

What this does not do

It reads @service(name = "…"), @DDSRequestTopic and @DDSReplyTopic (annotated_topics_expr) and hands the names to zerodds_rpc::requester::Requester::with_options as AnnotatedTopics; crates/rpc/src/topic_naming.rs composes the topic names of §7.4.1 and §7.4.2 from them.

Modules

type_information

The XTypes description of the topic types of the Enhanced Service Mapping (DDS-RPC 1.0 §7.5.1.2): the CompleteTypeObject of ${I}_Request and ${I}_Reply and of every type they name.

Enums

RustInterfaceError

Why an interface did not become a Rust binding.

Functions

rpc_layout_key

The LayoutKey every synthesized topic type’s codec is built under. See the module doc.

rpc_layout_key_xcdr1

The LayoutKey of the XCDR1 (classic CDR) codec of every synthesized topic type, the second pair CodecVariant::XCDR1 writes. DDS-RPC 1.0 §7.5.1.1: the Basic Service Mapping is for DDS 1.3.

rust_interface_pairs

The Rust declarations and runnable binding every interface of ast produces, each paired with the module it belongs in so a caller can fold it into the same tree crate::adapter::cst::nest_by_module builds for everything else.

rust_interface_pairs_with

rust_interface_pairs for the given service mapping.

xcdr1_capable_types

The declared types that have an XCDR1 codec pair (crate::encode::rust_codec_pair under rpc_layout_key_xcdr1). crate::generate emits those pairs for a model with interfaces, and the topic types’ XCDR1 codec calls them.