Skip to content

Conversation

@Lokomojo
Copy link

@Lokomojo Lokomojo commented Dec 8, 2025

clang-format can pick a parent directory’s config when formatting generated files, leading to mismatches with checked-in headers and failing compare steps. This change ensures the repository’s .clang-format is used consistently.

Generated files are written under the build tree, which may not contain a .clang-format. clang-format searches upward and can apply an unrelated config, causing byte-level diffs and verification failures.

In cmake/modules/HCT.cmake, we mirror the repository’s .clang-format into the DXC build root so clang-format’s upward search finds the intended config.

@damyanp
Copy link
Member

damyanp commented Dec 8, 2025

I worry this could lead to another hard to diagnose bug where someone adds a .clang-format to a subdirectory that has a generate header in it.

Would a more appropriate fix be to run the clang-format process over the file once it is in the final location where it will be checked in?

@Lokomojo
Copy link
Author

Lokomojo commented Dec 8, 2025

The build system runs clang-format at build time on generated content, and compares to checked in content. The generated files are not checked in unfortunately.

It's definitely undefined behaviour to run clang-format without a config in the build tree (it will only find the one in the project root if the build directory happens to be inside the project root)

@damyanp
Copy link
Member

damyanp commented Dec 8, 2025

Can --assume-filename=<string> help here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: New

Development

Successfully merging this pull request may close these issues.

2 participants