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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
