chore: Apply clang-format to entire codebase#2820
Conversation
|
Too many files changed for review. ( |
If I remember correctly, we intentionally chose left alignment with a 4-character spacing. |
Thanks. Updated description, accidentally pasted older version. This line wasn't changed. |
|
What is the correct strategy to migrate old branches to new main after the formatting was merged into main? |
|
One needs to switch to their branch, rebase, clang-format and commit. Step 1 — Checkout your feature branchgit checkout my-feature-branchStep 2 — Pull the
|
|
Did you test it? Does it work? This does not look as if it would work. I would expect the formatting needs to be merged into each commit of the branch? |
Can you plz add short code examples before and after the changes? |
This PR applies a repository-wide mechanical reformatting across all project source code using
clang-format.This is the successor to the original formatting attempt in PR #2638 (submitted by @DevGeniusCode). Following up on the community poll in Discord ("Apply clang-format on all code", which passed with 53%), this PR establishes the formatting baseline. Because the output is 100% automated, if conflicts arise from other PRs landing before this one, regenerating the diff is trivial (re-run the formatter and force-push).
A follow-up PR will add a
.git-blame-ignore-revsfile containing the commit hash of this formatting pass so thatgit blame(both locally and on GitHub) automatically skips over the formatting changes and preserves the historical authorship of every line.What Changed vs PR #2638
Three config adjustments have been applied based on review feedback and legacy toolchain compatibility:
UseTab: ForIndentation: Fixes the tab-space rendering mismatch in preprocessor block comments on GitHub (where GitHub defaults to tab=8, causing space-aligned block comments inside tab-indented preprocessor blocks to look misaligned). This resolves the issue without having to touch the source file comments themselves.SpacesInAngles: Leave: Retains existing spacing inside template brackets (e.g., keeping> >rather than collapsing them to>>), which is required for legacy C++98 / VC6 compiler compatibility.Cpp11BracedListStyle: false: Prevents the formatter from collapsing braced initializer lists to C++11 single-line style, maintaining Allman brace layout consistency.All other open review items from PR #2638 have been resolved, are hardcoded
clang-formatparser behaviors (such as the Doxygen Javadoc star alignment), or have since landed onmain.Key Legacy & Toolchain Compatibility Settings
To ensure the codebase continues to compile cleanly on both modern toolchains (VS2022) and the legacy target toolchain (Visual C++ 6), the following settings are established in
.clang-format:SpacesInAngles: Leave):Prevents
clang-formatfrom collapsing nested template arguments (e.g.,std::vector<std::vector<int> >to>>). VC6 and older compilers misparse>>as a right-shift operator. PR chore: Prevent conflict between clang-format and pre-C++11 nested template parsing #2760 (and its closed predecessor PR refactor: Extract nested templates into typedefs for legacy compatibility #2642) already resolved the instances where it was collapsed, and this setting ensures it stays that way.Cpp11BracedListStyle: false):Prevents formatting braced-init-lists in C++11 style, which causes parsing issues on legacy compilers.
clang-formathas known parser conflicts with MSVC-style inline assembly blocks when not enclosed in curly braces (which can cause the formatter to join assembly lines and break compilation). These have been pre-emptively wrapped in curly braces (__asm { ... }) inmainvia PR chore: Prevent conflict between clang-format and MSVC by wrapping inline assembly blocks in curly braces #2811, making the formatter pass entirely safe.Problems regarding assignment formatting split across macros have been pre-emptively addressed by PR refactor: Eliminate macro-split assignments #2641.
Scope & Merging Strategy
The PR includes the full codebase diff across all source files.
mainbefore this one, resolving conflicts is trivial: we simply re-run the formatter locally on top of the updatedmainbranch and force-push.Zero-Trust Verification
Reviewers can verify that this PR is 100% mechanically generated with no manual edits by running the following steps directly from
mainwithout checking out this branch:Step 1 — Download the
.clang-formatfile from this PRStep 2 — Run the formatter locally
Step 3 — Compare local changes with the PR diff
Expected result: The
diffoutput must be completely empty. If silent, it guarantees the PR contains only tool-generated formatting changes.How to Migrate Existing Feature Branches
If you have an active feature branch developed before this bulk formatting pass, you can migrate it to the new formatted
mainbranch cleanly without manual conflict resolution by letting Git ignore whitespace during the rebase, and then formatting your changes at the end:Step 1 — Checkout your feature branch
Step 2 — Pull the
.clang-formatconfig frommainStep 3 — Rebase onto
mainignoring whitespace changes(Git's
-Xignore-all-spaceoption tells the merge engine to ignore whitespace differences when replaying your commits on top of the formattedmain, allowing your logical changes to merge cleanly).Step 4 — Run the formatter to format your edits
Once the rebase completes, format the codebase to clean up the lines you edited:
Step 5 — Commit the formatting cleanup
git add -A git commit -m "chore: apply clang-format"