Fix line endings in co19 repository

[sgrekhov]

Some of the files in co19 repository have CRLF line ending. Need to change it to standard LF but add one test with CRLF line ending to check that tools accept it

See #2240 (comment)

[eernstg]

The new CRLF test could have all combinations (a line ending in \n, one ending in \r\n, one ending in \n\r, one ending in just \r, just so we know that this doesn't crash the parser ;-).

[sgrekhov]

The new CRLF test could have all combinations (a line ending in \n, one ending in \r\n, one ending in \n\r, one ending in just \r, just so we know that this doesn't crash the parser ;-).

All tests in this repository now have LF line ending. Added two tests that check that CRLF (Windows) and CR (Old Mac) line endings are supported. As for LFCR (\n\r) it's something non-standard. Is it used somewhere? Do we really need to support it?

[eernstg]

LFCR (\n\r) it's something non-standard. Is it used somewhere? Do we really need to support it?

I think we can potentially have any and all combinations of line ending characters (for example, because a file gets created on Linux and edited on Windows and then on an old Mac, etc), and the grammar says that they are all possible.

For example, LINE_BREAK derives both \n and \r, so we can have a location in the source code where there is an arbitrary string of \n and \r characters in any order. We don't have to worry about whether that's 1000 lines or 514 lines, because it's never significant for Dart whether we have one new line or multiple (we only rely on whitespace for disambiguation of declarations like @foo (int, int) f() => throw 0;, and the parser should be able to handle it no matter how many lines there are).

So it could still be useful to have that check: "weird combinations of line endings in the same file will not crash the parser". ;-)

[eernstg]

Just in case someone at some point in the future runs dos2unix on everything, is there a way to ensure that this very small set of files where it matters can be checked against a known value (perhaps on submit):

> sha1sum line_endings_cr_t01.dart
e5f6d574fd33f3aaf7ba24701d9f8472ba4cd175  line_endings_cr_t01.dart

[sgrekhov]

Just in case someone at some point in the future runs dos2unix on everything, is there a way to ensure that this very small set of files where it matters can be checked against a known value (perhaps on submit):

> sha1sum line_endings_cr_t01.dart
e5f6d574fd33f3aaf7ba24701d9f8472ba4cd175  line_endings_cr_t01.dart

I'm sure that it's possible but I don't see an immediate solution. As far as I can see SDK tests below also don't have such protection

tests/language/string/multiline_newline_cr.dart
tests/language/string/multiline_newline_crlf.dart
tests/language/string/multiline_newline_lf.dart
tests/language_2/string/multiline_newline_cr.dart
tests/language_2/string/multiline_newline_crlf.dart 
tests/language_2/string/multiline_newline_lf.dart 
tests/lib_2/mirrors/method_mirror_source_line_ending_cr.dart
tests/lib_2/mirrors/method_mirror_source_line_ending_crlf.dart
tests/lib_2/mirrors/method_mirror_source_line_ending_lf.dart
tests/lib_2/mirrors/method_mirror_source_line_ending_test.dart
tests/lib/mirrors/method_mirror_source_line_ending_cr.dart
tests/lib/mirrors/method_mirror_source_line_ending_crlf.dart
tests/lib/mirrors/method_mirror_source_line_ending_lf.dart

Probably it makes sense to create SDK infra issue. But there's a contra as well. This protection will complicate process of changing these tests

[eernstg]

Makes sense! I'm trying out the idea in dart-lang/sdk#53398.