Skip to content

idl/esi: share one identifier-naming policy across both codegen planes #116

Description

@patdhlk

Context

Surfaced by the review of #113. crates/taktora-idl-codegen/src/naming.rs re-implements the same identifier-sanitisation policy that crates/taktora-ethercat-esi-codegen/src/naming.rs already owns:

  • a near-identical Rust-2024 KEYWORDS list,
  • word segmentation on lower/digit→upper transitions and separator runs,
  • snake_case / PascalCase joining,
  • keyword escaping and leading-digit prefixing.

(Device plane: snake_field_string / pascal_segment / sanitise_ident. Message plane: words / snake / pascal.)

Problem

Two independent copies of the same policy drift on edge cases (e.g. how AI TxPDO-Map or an all-separator name segments). The same source name can then map to different Rust identifiers across the device and message toolchains, so a fix or convention applied to one never reaches the other — double maintenance and inconsistent generated APIs.

Note: the two implementations already differ subtly today. Unifying them must preserve each plane's current generated output (both crates' naming tests must stay green), or any intended behaviour change must be called out explicitly. This is why it's separate from #113 — it touches the device-plane crate.

Proposed direction

  • Extract a shared crate (e.g. taktora-codegen-naming) holding the segmentation + keyword/leading-digit policy.
  • Have both taktora-idl-codegen and taktora-ethercat-esi-codegen depend on it; keep plane-specific naming (device product-string selection, revision suffixes, PDO segments) in their own crates on top of the shared primitives.
  • Reconcile any edge-case divergence deliberately, with tests pinning the agreed behaviour.

Acceptance

  • One implementation of the word-segmentation + sanitisation rules, used by both planes.
  • Existing naming tests in both crates pass (or intended changes are documented).

Refs: #113 (review verdict: PLAUSIBLE — DRY/maintainability, no current incorrect output)

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions