Repository navigation
Description
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.
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsDone
Activity
bocchino commentedon Sep 20, 2026
@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!Dev-next-gen commentedon Sep 20, 2026
@bocchino Done — opened as #1119 against
release/v3.3.1, as you asked. It's the two-line dispatch fix inFormatCppWriterplus a test case where theF32alias now generates%.3einstead 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)