[Lldb-commits] [clang] [clang-tools-extra] [flang] [lldb] [llvm] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

via lldb-commits lldb-commits at lists.llvm.org
Fri Oct 18 07:07:18 PDT 2024


ldrumm wrote:

There are a couple of things to unpack here

> a number of test input files need to be in LF form to work

Which ones? Either there's a bug in a parser somewhere, 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.

> 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`:

>  core.eol
           Sets the line ending type to use in the working directory for files that are marked as text (either by having the text attribute set, or by having text=auto and
           Git auto-detecting the contents as text). Alternatives are lf, crlf and native, which uses the platform’s native line ending. The default value is native. See
           gitattributes(5) for more information on end-of-line conversion. Note that this value is ignored if core.autocrlf is set to true or input.

and

>  core.autocrlf
           Setting this variable to "true" is the same as setting the text attribute to "auto" on all files and core.eol to "crlf". Set to true if you want to have CRLF line
           endings in your working directory and the repository has LF line endings. This variable can be set to input, in which case no output conversion is performed.


> Can we revert this until we figure out these bits

Sure, but like I said, I'm happy to fix these broken cases. The old configuration was broken, but not in a controllable way, so I think it's reasonable to fix up the broken tests and move forward. Perhaps we also need clearer documentation?



https://github.com/llvm/llvm-project/pull/86318


More information about the lldb-commits mailing list