[sundermann]

Adds optional From<Concrete> implementations for polymorphic choice enums so callers can construct them with .into(). Select RenderStep::PolymorphicFrom alongside dynamic-to-choice conversion. The step is absent from the default pipeline.

Changes

• Add an independent PolymorphicFromRenderStep, including traversal of unflattened content enums. Type and serialization renderers need no conversion hooks, and RendererFlags::all() does not enable the feature.
• Respect generated variant names, module paths, boxing, and allocator configuration. Skip ambiguous payloads using conservative type comparison.
• Document that external Rust aliases are opaque: a custom Text aliasing String alongside a String payload can cause E0119. Use a newtype or omit the step in that case.
• Consolidate alias and allocator coverage, remove redundant fixtures and substring assertions, and test standalone composition and explicit opt-in.

Public API addition: config::RenderStep gains PolymorphicFrom; exhaustive matches must handle the new variant. The concrete PolymorphicFromRenderStep is also exported. Default generated output is unchanged.

Checklist

• Tests for the change (a bug fix has a test that fails without the fix)
• Changed snapshots are regenerated with update-expectations and reviewed
• cargo fmt, cargo clippy and cargo test pass (see CONTRIBUTING.md)
• Breaking changes of the public API or the generated code are described above

[Bergmann89]

Thanks, I like the feature!

I would prefer to implement it as its own render step instead of a renderer flag that is hooked into the four type renderers. The conversions do not depend on anything of these renderers, they only need the ComplexDataEnum. A separate step can match DataTypeVariant::Complex in render_type and walk ComplexData::Enum { type_, content_type } (including the content type for the unflattened case). It is then completely independent of the other steps, users add it with something like RenderStep::PolymorphicFrom to the pipeline, and RendererFlags::POLYMORPHIC_FROM is not needed anymore (which also avoids that RendererFlags::all() enables it).

Please also document in the step docs that payloads which only differ by an external type alias cannot be detected: the comparison uses the final identifiers, so a custom type Text with type Text = String next to a String variant gets two From impls for the same type and fails with E0119. The generator cannot see user aliases, so a note (use a newtype or do not use the step) is enough.

The remaining comments are about the tests.

[sundermann]

Thanks for the review, updated the PR and the implementation is cleaner now.