[Mlir-commits] [clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
llvmlistbot at llvm.org
llvmlistbot at llvm.org
Thu Apr 25 09:07:14 PDT 2024
ldrumm wrote:
@compnerd I just realised I didn't respond to your concern. Apologies.
> I think that the concern that I have is that do we have sufficient testing for supporting line-ending dependent behaviour in the compiler?
For the first part: I don't know that it matters, since this patch changes how the LLVM source code is stored, but not how its parsers operate. In any case, we run parser testing on LF and CRLF systems since the precommit testing runs on Linux, and Win32 at least. In addition, and there are several tests dedicated to line ending, so I think we should be good there. Happy to tend to this and fix anything I've missed if someone lets me know something is broken after we merge.
As for the second part
>Additionally, do we have sufficient documentation for others to figure out how to ensure that git does not munge the line endings if they are introducing a test which is dependent on it? In such a case, how do we ensure that they are aware that the SCM will do so without actually checking the post-commit state with a hex editor?
I don't think we do, but also this patch doesn't really change the problem since right now basically *anything* can happen due to local configuration overrides (`~/.gitconfig`). I'll add a comment to the testing infrastructure page to be mindful of how line endings are storedand link to the `.gitattributes` documentation. Does that sound enough?
https://github.com/llvm/llvm-project/pull/86318
More information about the Mlir-commits
mailing list