Fix CRLF line endings to LF #4941
Conversation
135305f to
c847dd4
Compare
|
The auto correction of line endings broke a test: Test that Unicode escape sequence in single quoted here string is not processed The test data is using a multiline Here string and it ends up with \n for newlines. The test is using powershell escaped 'r'n so the strings no longer match. |
|
@dantraMSFT I'll fix that and resubmit with [feature] so essentially all tests are run |
| @@ -317,7 +317,7 @@ foo``u{2195}abc | |||
|
|
|||
| '@ | |||
| "@ | |||
| $result | should be "`r`nfoo``u{2195}abc`r`n" | |||
| $result | should be "`nfoo``u{2195}abc`n" | |||
There was a problem hiding this comment.
We should not have parser tests that are sensitive to the line feeds of the file.
Such tests should generate the strings with `n or `r`n as desired, and if it must be read from a file (which parser tests normally don't need) - then generate the file.
There was a problem hiding this comment.
This test is only for validating that the unicode escaped character isn't processed. The newlines are not important for this test unless I'm misunderstanding this test case.
There was a problem hiding this comment.
IIRC it is not line feeds of the file but the fact that PowerShell here strings use `n. This test is checking Unicode esc sequences inside a here string. OTOH, we don't have to test the entire string. The point of this test was to ensure we ignore this esc seq in a single quoted here string. This test could use a regex match to look for the esc seq.
There was a problem hiding this comment.
IIRC, here strings contain whatever newline the file had - it does no translation.
But the point here is - the test shouldn't be sensitive to that, e.g. if git checkouts out the file with `r`n, test shouldn't fail.
There was a problem hiding this comment.
OK, I trust your memory over mine. :-) At the console, here strings use `n. But in a file, yeah, I guess it makes sense that here string uses whatever the file uses for eol.
There was a problem hiding this comment.
I'll change it to a regex to handle both cases
0fdd9ec to
0dd05ae
Compare
|
Need to figure out how to remove the Pester submodule change from the oldest commit in this PR |
0dd05ae to
97c6960
Compare
|
Well, messed up this PR trying to remove the submodule change. Will try again in new PR. |
Was hoping to take this change later, but due to the change in .gitattributes that we merged, it appears that any new clone will show these files as modified (as git auto fixes them). For anyone with an existing clone, when they fetch/pull, a subset of files that changed from their fork will also be autocorrected. Might as well take this now.