-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ensure that checkout is with \n line endings #62564
Conversation
During installation of mingw, at least, the git directories change, so we need to reset the core.autocrlf config to false. Once we finish checking out submodules, check that the line endings are \n and not \r\n.
@bors r+ p=100 |
📌 Commit df725c2 has been approved by |
…bini Ensure that checkout is with \n line endings During installation of mingw, at least, the git directories change, so we need to reset the core.autocrlf config to false. Once we finish checking out submodules, check that the line endings are \n and not \r\n. Artifacts were built via the last try on #62545; I've manually confirmed that `install.sh` appears to no longer have `\r\n` line endings. Fixes #62276.
☀️ Test successful - checks-azure, checks-travis, status-appveyor |
@rustbot modify labels: beta-nominated T-infra Nominating for beta backport. |
If we can control this in each repository would that perhaps be a better solution? It seems odd to just sort of reconfigure git a bunch of time seemingly randomly in the azure configuration... |
The problem is likely to come in e.g. tests, etc. as well -- IMO, this is a bug in pipelines that they set CRLF line endings to enabled for us, we just need to work around that. |
But it's not problematic in the sense of all our tests pass? W/e azure does by default seems to run for our test suite since it's all passing? This just seemed like an overly large change to our configuration on Azure relative to the change here |
I believe compiletest intentionally normalizes line endings and such so that's probably why our tests are passing. I do think it's plausible we can get a more targeted fix in -- this was mostly intended to "stop the bleeding" and we can revert and apply selective patches if that route would be preferable to you. I mostly wanted it done in rust-lang/rust itself so that we can avoid having to patch multiple repositories to disable autocrlf, but maybe that was a false fear. We'll need to update rust-lang/rust's .gitattributes anyway because they're insufficient to remove CRLF from all files, e.g., the I also think I can relatively easily reduce the amount of calls to ~2 -- I think one of them in this PR is probably not necessary, though I can't be certain. |
FWIW Miri tests were failing until |
[beta] Rollup backports Cherry picked: * rustc_target: avoid negative register counts in the SysV x86_64 ABI. #62380 * Fix ICEs when `Self` is used in type aliases #62417 * Raise the default recursion limit to 128 #62450 * Handle errors during error recovery gracefully #62604 * Correctly break out of recovery loop #62607 * Cancel unemitted diagnostics during error recovery #62666 * ci: pin awscli dependencies #62856 * Ensure that checkout is with \n line endings #62564 Rolled up: * [beta] Backport #62615 #62793 * [beta] Fix #62660 #62792 r? @ghost
[beta] Rollup backports Cherry picked: * rustc_target: avoid negative register counts in the SysV x86_64 ABI. #62380 * Fix ICEs when `Self` is used in type aliases #62417 * Raise the default recursion limit to 128 #62450 * Handle errors during error recovery gracefully #62604 * Correctly break out of recovery loop #62607 * Cancel unemitted diagnostics during error recovery #62666 * ci: pin awscli dependencies #62856 * Ensure that checkout is with \n line endings #62564 Rolled up: * [beta] Backport #62615 #62793 * [beta] Fix #62660 #62792 r? @ghost
During installation of mingw, at least, the git directories change, so
we need to reset the core.autocrlf config to false.
Once we finish checking out submodules, check that the line endings are
\n and not \r\n.
Artifacts were built via the last try on #62545; I've manually confirmed that
install.sh
appears to no longer have\r\n
line endings.Fixes #62276.