--to rust output is not compilable in a lint-clean crate: no derives, camelCase fields

[MelbourneDeveloper]

Context

We generate Dart metaprogramming tooling in Rust (dmx) and our house rules mandate that all models are code-generated with typeDiagram. We hit a wall trying to use --to rust for the engine's model types.

Schema

type RawParam {
  name: String
  typeText: Option<String>
  isNamed: Bool
  isRequired: Bool
  defaultValue: Option<String>
}

union DeclKind {
  Class
  Enum
}

What typediagram --to rust probe.td emits

pub struct RawParam {
    pub name: String,
    pub typeText: Option<String>,
    pub isNamed: bool,
    pub isRequired: bool,
    pub defaultValue: Option<String>,
}

pub enum DeclKind {
    Class,
    Enum,
}

Problems

1. camelCase field names. Rust's naming convention is snake_case. The output triggers non_snake_case warnings, so any crate building with -D warnings (ours does: cargo clippy --all-targets -- -D warnings) fails outright. The only escape is #![allow(non_snake_case)] over generated and consuming code, which then hides real defects. The Dart target correctly emits idiomatic Dart (camelCase), so per-language identifier casing is clearly intended — it just isn't applied to the Rust target.

2. No derives, and no way to ask for them. Without at least #[derive(Debug, Clone, PartialEq)] the types can't be compared in tests, logged, or stored in collections. Every real consumer needs some derive set, and there's no flag or schema-level annotation to request one.

3. No doc-comment passthrough. There appears to be no way to attach documentation to a type or field in the schema and have it reach /// in the output, so generated models arrive undocumented — a hard blocker where documentation is mandatory.

4. Generated enums lack a payload form. union variants with payloads are documented, but it's unclear whether the Rust target emits data-carrying variants (Circle { radius: f64 }) or unit-only variants.

What would unblock us

• Rust identifiers converted to snake_case (types stay PascalCase), matching how the Dart target already adapts to its language.
• A way to request derives — a CLI flag (--rust-derive Debug,Clone,PartialEq) or a schema annotation.
• Doc comments in the schema, emitted as ///.

Happy to test a branch.

Also

tdbin docs (https://typediagram.dev/docs/tdbin.html) show Rust and TypeScript only. Is a Dart codec target planned? For a Dart-facing toolchain that's the half that matters, and it's the documented wiring path.