[Openmp-commits] [clang] [clang-tools-extra] [flang] [lldb] [llvm] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
Martin Storsjö via Openmp-commits
openmp-commits at lists.llvm.org
Fri Oct 18 09:14:35 PDT 2024
mstorsjo wrote:
> > a number of test input files need to be in LF form to work
>
> Which ones?
A whole bunch of them. @AaronBallman's link to https://buildkite.com/llvm-project/github-pull-requests/builds/111165#0192a01b-d3ac-44ad-abff-e53ac4a206ab shows mostly what I saw. If including `clang-tools-extra` and `llvm` in the set of tests to run, I have failures in the following tests as well:
```
Clang Tools :: clang-move/move-used-helper-decls.cpp
LLVM :: MC/ELF/warn-newline-in-escaped-string.s
LLVM :: TableGen/x86-fold-tables.td
LLVM :: tools/llvm-rc/tag-html.test
lit :: shtest-shell.py
```
> Either there's a bug in a parser somewhere,
In the vast majority of cases, it's not a bug in a parser, but a test that relies on the exact contents of the source files. E.g. for `tools/llvm-rc/tag-html.test` I would guess that the issue is that the test takes a text file (which now has variable line endings) and includes it in a binary resource file, and checks the output to match bitwise the expected output.
In my nightly run of compiler-rt tests https://github.com/mstorsjo/llvm-mingw/actions/runs/11395494568/job/31717433112, I had the following failures:
```
Failed Tests (5):
Profile-x86_64 :: instrprof-gcov-exceptions.test
Profile-x86_64 :: instrprof-gcov-multiple-bbs-single-line.test
Profile-x86_64 :: instrprof-gcov-one-line-function.test
Profile-x86_64 :: instrprof-gcov-switch.test
Profile-x86_64 :: instrprof-gcov-two-objects.test
```
I think the issue here may be something around testing the exact amount of whitespace somewhere or so.
Mostly "brittle" tests that don't expect the source files to vary.
> or I missed some test files. In either case I'd like to fix the issue. I watched the buildbots quite closely last night and only noticed failures in ARM frame lowering - which isn't this, I think.
Did you do a test run on Windows? Even on Linux, I guess it should be possible to check out the code, forcing Git to prefer checking out text files as CRLF, so you could experience the same amount of fallout.
> > Now after this change, due to the added .gitattributes which overrides the core.autocrlf setting, these files get checked out with CRLF newlines (as the native form for the platform).
>
> It's my understanding that `text=auto` does not override `core.autocrlf`. As far as I can tell from the documentation it honours the user's configuration for `core.eol` in combination with `core.autocrlf` - from `git config --help`:
This doesn't match my experience.
See https://github.com/mstorsjo/llvm-project/commit/inspect-newlines for a test github actions job that shows checking out the repo on Windows. First we check out an old branch, with default settings - we get CRLF. Then we set `core.autocrlf=false` and retry the above, we get a file with LF newlines. Then we check out the new version with gitattributes, and we notice how we now suddenly are getting CRLF again, despite our setting. See https://github.com/mstorsjo/llvm-project/actions/runs/11407224268 for the actual run log.
Feel free to play around with such an action, to come up with a better way of checking it out while still getting LF newlines - but this is the way I have been doing it (which is scripted in a number of places), and I would expect that many others have the same setup.
https://github.com/llvm/llvm-project/pull/86318
More information about the Openmp-commits
mailing list