Revert unintended CR/LF changes to non-3C files that originated in 277d84a5841634783e7d3752707e2a1e4e57a930.

[mattmccutchen-cci]

We first submitted them in PR #837, but Mandeep noticed
(#837 (review))
and the unintended changes were removed from that PR in
74bfcaf. However, when the squash of
PR #837 was merged with the original commits in
cfc998e, the unintended changes were
incorrectly retained. They got submitted again in the next 3C PR
(#891), and no one noticed that time.

[dtarditi]

@mgrang, do you have any concerns about this change? This change looks good to me.

[mgrang]

LGTM. @mattmccutchen-cci Could you please verify if the validations are passing on Linux and Windows with this change?

[mattmccutchen-cci]

@mattmccutchen-cci Could you please verify if the validations are passing on Linux and Windows with this change?

I could run the 3C regression tests, but I'm not familiar with how to run your full set of tests (which presumably includes the 3C regression tests). Can you just run them as you would on any other PR?

[mgrang]

@mattmccutchen-cci Could you please verify if the validations are passing on Linux and Windows with this change?

I could run the 3C regression tests, but I'm not familiar with how to run your full set of tests (which presumably includes the 3C regression tests). Can you just run them as you would on any other PR?

You can run ninja check-all on Linux and Windows.

[mattmccutchen-cci]

ninja check-all passes on my revert-unintended-crlf-changes-test-merge in our Linux environment. check-all failed to build in our Windows X64 environment with Visual Studio 2019 Community 16.8.4 due to this problem; the same problem occurs without this PR. (check-clang-3c is not affected.) Whatever we blame for the problem, it supposedly no longer occurs with LLVM 11.

I thought I've seen you trigger some process that runs the tests in your environment and posts GitHub status checks on the PR, and I assume that for whatever reason, it isn't affected by the build failure. Can you just use that process?

[mgrang]

ninja check-all passes on my revert-unintended-crlf-changes-test-merge in our Linux environment. check-all failed to build in our Windows X64 environment with Visual Studio 2019 Community 16.8.4 due to this problem; the same problem occurs without this PR. (check-clang-3c is not affected.) Whatever we blame for the problem, it supposedly no longer occurs with LLVM 11.

I thought I've seen you trigger some process that runs the tests in your environment and posts GitHub status checks on the PR, and I assume that for whatever reason, it isn't affected by the build failure. Can you just use that process?

We discussed the Windows X64 build issue with @mwhicks1 and he says you should be able to build Windows X64 version without issues.

[mwhicks1]

@mgrang What I said is what you've quoted in the issue: We can successful fun check-clang-3c on Windows X64. This build target requires clang, 3c, and other tools. So in this sense we can "build Windows X64 version."

I don't know what's in check-all that's the problem, but it's not an inability to construct Checked C's clang on Windows X64.

[mgrang]

I will go ahead and merge this PR. I will let you know in case our ADO validations break after the merge.

[mattmccutchen-cci]

Thanks @mgrang! Hopefully we get these testing process issues sorted out over time.