fix(lint): .clang-format uses Zephyr's config verbatim, not tuned for this project #45

Closed
opened 2026-07-22 15:06:16 +00:00 by hoogv · 0 comments
hoogv commented 2026-07-22 15:06:16 +00:00 (Migrated from codeberg.org)

Description

.clang-format (added under feat(c-lint)) is Zephyr's own config file copied verbatim -- IndentWidth: 8, UseTab: ForContinuationAndIndentation, Zephyr-specific ForEachMacros/AttributeMacros/IncludeCategories lists that don't apply to this project at all.

This surfaced concretely while landing DMM (#44): the new lint.yml clang-format job (#39) failed on the newly-added hal/registers/component/dmm.h/instance/dmm.h. Running clang-format -i with the current config produces badly mangled output -- switches to 8-space tabs, breaks apart the hand-aligned CMSIS-style bitfield comment tables every register header in this project relies on for readability (see the job log, lint-clang-format-7881508.log). This isn't just a one-off gap on DMM's files; it would do the same to every future register header (DSS Cache, EDMA, ePWM, ESM, and beyond) and to any future hal/mss/hal/dss driver code.

Scope

  • Retune .clang-format to this project's actual established style: 4-space indent, no tabs, brace-on-its-own-line, unwrapped long doc comments (this project's headers rely on single-line TRM-cross-reference comments that shouldn't be reflowed), and drop the Zephyr-specific macro/include-category lists that don't apply here
  • Confirm clang-format --dry-run produces reasonable (aligned, readable) output on a representative header, even if not byte-identical to the existing hand-tuned alignment in already-landed files (out of scope to reformat those retroactively, per lint.yml's existing changed-files-only design)

Functional Impact

None -- lint-tooling config only, no product/driver code changes.

Regulatory Impact

None

QMS Impact

None

Risk Impact

No -- existing risk coverage sufficient.

Relates to #38, #11

### Description `.clang-format` (added under `feat(c-lint)`) is Zephyr's own config file copied verbatim -- `IndentWidth: 8`, `UseTab: ForContinuationAndIndentation`, Zephyr-specific `ForEachMacros`/`AttributeMacros`/`IncludeCategories` lists that don't apply to this project at all. This surfaced concretely while landing DMM (#44): the new `lint.yml` `clang-format` job (#39) failed on the newly-added `hal/registers/component/dmm.h`/`instance/dmm.h`. Running `clang-format -i` with the current config produces badly mangled output -- switches to 8-space tabs, breaks apart the hand-aligned CMSIS-style bitfield comment tables every register header in this project relies on for readability (see the job log, `lint-clang-format-7881508.log`). This isn't just a one-off gap on DMM's files; it would do the same to every future register header (DSS Cache, EDMA, ePWM, ESM, and beyond) and to any future `hal/mss`/`hal/dss` driver code. ### Scope - [x] Retune `.clang-format` to this project's actual established style: 4-space indent, no tabs, brace-on-its-own-line, unwrapped long doc comments (this project's headers rely on single-line TRM-cross-reference comments that shouldn't be reflowed), and drop the Zephyr-specific macro/include-category lists that don't apply here - [x] Confirm `clang-format --dry-run` produces reasonable (aligned, readable) output on a representative header, even if not byte-identical to the existing hand-tuned alignment in already-landed files (out of scope to reformat those retroactively, per `lint.yml`'s existing changed-files-only design) ### Functional Impact None -- lint-tooling config only, no product/driver code changes. ### Regulatory Impact None ### QMS Impact None ### Risk Impact No -- existing risk coverage sufficient. ### Related Issues / PRs Relates to #38, #11
hoogv self-assigned this 2026-07-23 12:01:46 +00:00
hoogv added this to the Development project 2026-07-23 12:01:49 +00:00
Sign in to join this conversation.
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
opendutchsolutions.public/hal_awr6843#45
No description provided.