[all-commits] [llvm/llvm-project] 374a83: [libc] Write LF line endings from cmake_format.py ...

[Leo Camus via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 374a8320bf21962b6749965b97294e4815641cb6
      https://github.com/llvm/llvm-project/commit/374a8320bf21962b6749965b97294e4815641cb6
  Author: Leo Camus <leo.camus23 at gmail.com>
  Date:   2026-09-11 (Fri, 11 Sep 2026)

  Changed paths:
    M libc/utils/cmake_format.py
    M libc/utils/cmake_format_test.py

  Log Message:
  -----------
  [libc] Write LF line endings from cmake_format.py on every platform (#222742)

I ran the libc CMake formatter on Windows and it gave back a file whose
every line had changed:

```
$ printf 'add_library(foo  STATIC\n  a.c\n)\n' > CMakeLists.txt
$ python libc/utils/cmake_format.py -i CMakeLists.txt
Formatted CMakeLists.txt
$ python -c "print(open('CMakeLists.txt','rb').read())"
b'add_library(foo STATIC\r\n  a.c\r\n)\r\n'
```

`format_cmake_content()` joins its lines with `"\n"`, but
`process_file()` hands that string to `open(temp_file, "w",
encoding="utf-8")`, and a text-mode write substitutes the platform line
separator. So on Windows, reformatting one command in a file rewrites
the endings of the whole file. `.gitattributes` declares no `text`/`eol`
rules and `llvm/docs/GettingStarted.md` tells people to clone with
`core.autocrlf=false`, so nothing normalizes those endings back before
the commit.

The read side already normalizes: `open(..., "r")` gives universal
newlines, so a CRLF file is LF by the time the formatter sees it.
Passing `newline="\n"` on the write makes both ends agree and gives the
same bytes on every platform.

The same substitution applies to stdout, which affects the piped output
and the `--diff` text (a CRLF diff does not apply against an LF file),
so I configured stdout the same way in `main()`.

One behaviour change worth flagging: on Windows, a CMake file that
currently has CRLF endings and needs reformatting now comes out with LF
rather than CRLF. Files that are already formatted are not written at
all, before or after, since the comparison is made on the LF-normalized
read.

For the tests, everything in `cmake_format_test.py` today asserts on the
string returned by `format_cmake_content()`, so nothing covers what
lands on disk. I added two cases that compare the bytes on disk and on
stdout against that string. They fail on Windows before this change (the
assertion prints `b'...\r\n...' != b'...\n...'`) and pass after; on
Linux and macOS they pass either way, since the separator is already LF.
The file went from 47 to 49 tests, all passing under `python -m unittest
cmake_format_test`.

I did not have `black` available on that machine, so the added code
follows the surrounding style by hand rather than by running the
formatter.

AI tools used



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications