[devin-ai-integration]

Summary

Design-first spec update for nasa/fpp#665 (support bit fields in structs), per the Adding New Features to FPP process. Spec changes only — no compiler changes yet.

New struct member form, following the syntax direction suggested in the issue:

struct E {
  a: unsigned 3   # 3-bit unsigned field; FPP type U8
  b: signed 9     # 9-bit signed field; FPP type I16
  x: U32          # typed member
}

Key semantics:

• signed/unsigned become reserved words; bit width is an expression with 1 ≤ w ≤ 64.
• Member type is the smallest primitive integer type that fits the width; bit packing affects only the serialized form, not the in-memory representation.
• Consecutive bit field members form a bit field group, packed MSB-first in declaration order; group totals may be any bit count and are zero-padded to the next byte boundary (pad bits ignored on deserialization).
• Values must fit in the declared width (checked for default values).

Also updates keyword lists in run_prettify.js, fpp-mode.el, and fpp.vim per the wiki, and regenerates docs/fpp-spec.html (bulk of the diff; regenerated with Asciidoctor 2.0.26, byte-identical toolchain apart from the timestamp).

Pushed by Devin AI

Link to Devin session: https://nasa-jpl-demo.devinenterprise.com/sessions/35e224d305ae47afa1eb19e6f376adf5
Requested by: @thomas-bc-autobot

---

[devin-ai-integration]

Original prompt from thomas.boyer.chammard

There should be in the FPP repo a wiki, and in that wiki, it should describe the contribution process. I think the FPP team wants like a design first, and so that's like updating the spec in the first PR or something like that. Anyways, let's follow that. Let's make sure to follow that contribution process. And what I want is for FPP to implement a ticket that's open already. You should be able to find it, which is to have the ability to do bitfields in structs in FPP. Like when you serialize a struct, you can, instead of just having it be u8, like actual types, you could also have bitfields. And so I want to implement that in FPP. So let's first go look at the contribution process and then follow that to implement this feature. And ask questions if needed. For example, should we allow structs to have bitfields but not end up being either 8 or 16 or 32 or 64 bits? I'm not sure about that. Is that a good idea? Let me know.

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR that start with 'DevinAI' or '@devin'.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.

[devin-ai-integration]

Visual verification of regenerated docs/fpp-spec.html

Opened the checked-in HTML in Chrome and verified all new bit-field spec content renders correctly, including the "typed member" rename. All checks passed.

Struct Definitions — typed / bit field member forms & semantics ✅

Asciimath typeset by MathJax ✅ — 1 ≤ w_m ≤ 64 and both value ranges render with proper sub/superscripts:

Example struct E with syntax highlighting ✅

Serialized Sizes — bit field group bullets nested correctly ✅

Reserved words include signed / unsigned ✅

Also verified: cross-reference links ("primitive integer type" → §17.1, "serialized sizes" → §17.19, "bit field groups" → §5.13) all jump to the correct anchors.

Pushed by Devin AI