Skip to content

fpp-to-cpp drops rational format fields on aliases of F32 and F64 #1116

Closed

Description

@Dev-next-gen

When the type of a formatted element is a type alias whose underlying type is F32 or F64, fpp-to-cpp ignores the rational format field and emits the default %f.

Example:

type ATF32 = F32

array AliasTypeFormat = [3] ATF32 format "{.3e}"

The generated toString code contains:

tmp.format("%f", static_cast<F64>(this->elements[index]));

whereas the same array declared with F32 directly produces "%.3e". The precision and the e conversion are both lost, silently: fpp-check accepts the format string, because Analysis.computeFormat resolves the alias before testing isFloat, and there is already a test covering that (fpp-check/test/array/format_alias_float_not_int.fpp).

The cause is in FormatCppWriter.writeField: the rational case matches on the syntax of the type name node (tn.data match { case Ast.TypeNameFloat(_) => ... }), and an alias name parses as Ast.TypeNameQualIdent, so it never matches and falls through to the default format. The integer case immediately above already dispatches on s.a.typeMap(tn.id).getUnderlyingType, which handles aliases correctly. The gap between the two cases is what suggests this is unintended rather than a design choice.

This affects every entry point of the writer: telemetry channels, event parameters, struct members and array elements. It applies to {e}, {g} and {.Nf} as well as {.3e}.

I have a two-line fix that makes the rational case dispatch on the underlying type exactly like the integer case does, plus a test case added to the existing alias_type case in fpp-to-cpp/test/array with the reference output regenerated by update-ref. Before the fix that test fails with

-    tmp.format("%.3e", static_cast<F64>(this->elements[index]));
+    tmp.format("%f", static_cast<F64>(this->elements[index]));

and after it passes. When I regenerated the reference files with the patched compiler, the only files that changed were the four new ones for this case, so no existing reference output moves. sbt test reports 633 tests succeeded, 0 failed.

The branch is here if it helps you judge, and I have opened no pull request: main...Dev-next-gen:fpp:fix-format-alias-float

Following CONTRIBUTING.md, I am asking before implementing further rather than sending a pull request. If you would rather handle this yourselves, or if the behaviour is intended for a reason I have not seen, say so and I will leave it there.

Nothing this pipeline produces is submitted without human approval. The entire submission, the code change, the test case, the regenerated reference output and this description, was reviewed by a human before the pipeline was allowed to submit it. This includes the two-line dispatch change in FormatCppWriter.writeField and the alias_type test case in fpp-to-cpp/test/array that the fix relies on.

Found by a defect-hunting pipeline I build and run (Dev-next-gen), using Claude Code with Anthropic's Claude Opus 5.

(@Dev-next-gen)

Activity

  1. added theissue type on Sep 20, 2026
  2. moved this from CCB to In Progress in F´ Developmenton Sep 20, 2026
  3. bocchino commented on Sep 20, 2026

    @bocchino
    Collaborator

    @Dev-next-gen Good catch! This looks like a code gen bug. Please go ahead and make the PR against the release/v3.3.1 branch. Thanks!

  4. added this to the v3.3.1 milestone on Sep 20, 2026
  5. Dev-next-gen commented on Sep 20, 2026

    @Dev-next-gen
    ContributorAuthor

    @bocchino Done — opened as #1119 against release/v3.3.1, as you asked. It's the two-line dispatch fix in FormatCppWriter plus a test case where the F32 alias now generates %.3e instead of %f.

    And you're welcome. Contributing to the project that carries space discovery forward isn't a favor, it's a duty — glad to have caught this one.

    (@Dev-next-gen)

  6. moved this from In Progress to Done in F´ Developmenton Sep 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    code generationIssues related to code generation

    Type

    Projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions