Add a test for trimming leading whitespace in multiline strings

tests/language/multiline_strings_test.dart

+// Copyright (c) 2015, the Dart project authors.  Please see the AUTHORS file
+// for details. All rights reserved. Use of this source code is governed by a
+// BSD-style license that can be found in the LICENSE file.
+
+import "package:expect/expect.dart";
+
+main() {
+  Expect.equals('foo', '''  
+foo''');
+
+  Expect.equals('\\\nfoo', '''\\

[hausner, 2015/03/31 22:15:36]

I believe this expectation is wrong. The Spec essentially says that a backslash
in front of a space is swallowed, but not any arbitrary backlsash.

[hausner, 2015/03/31 22:33:04]

My bad. This expectation is right.

+foo''');
+
+  Expect.equals('\t\nfoo', '''\t
+foo''');

[hausner, 2015/03/31 22:33:04]

This multiline string should be equal to 'foo', since the first line only
contains whitespace (a tab) before the newline.

[Paul Berry, 2015/03/31 23:33:03]

The relevant spec text is: "If the first line of a multiline string consists
solely of the whitespace characters defined by the production WHITESPACE,
possibly prefixed by \, then that line is ignored, including the new line at its
end".

It isn't manifestly stated in the spec text whether it's referring to the raw
uninterpreted characters of the string as they appear in the source file, or the
characters that result after escape sequences have been interpreted.  But we
have to choose one interpretation and use it consistently, and reading between
the lines, I think it's pretty clear that the intention was to refer to the raw
uninterpreted characters.  (If the intention had been to refer to the characters
that result after escape sequences have been interpreted, then there would have
been no need for the phrase "possibly prefixed by \"; in fact, the presence of
this phrase would cause even "\\ " to be trimmed, which matches neither VM nor
Dart2js behavior, and which I think would be very unexpected.)  So under my
interpretation, Brian's test is correct--"\t" should not be trimmed from the
string, because "t" is not a whitespace character.

Should we ask Gilad to weigh in?

[gbracha, 2015/04/02 19:25:57]

The idea was (I believe) to ignore invisible stuff people may have typed after
the opening of the string.  Maybe we should have left it at that, but someone
noted that say, tab and \ followed by tab were the same. But the argument would
apply to \t. It is also much easier to understand that way.

The wording should be clarified, but basically, if it *any* kind of whitespace,
you ignore it. So while Paul and Brian's interpretation is sensible vis-a-vis
the wording, I don't think an ordinary human would expect such subtlety.

In any case, at some point it would make sense to reword the spec. since it
seems insufficient verbiage was dedicated to this weighty topic.

+
+  Expect.equals('foo', '''\
+foo''');
+
+  Expect.equals('foo', '''\ \
+foo''');
+
+  Expect.equals(' \nfoo', '''\x20
+foo''');
+
+  String x = ' ';
+  Expect.equals(' \nfoo', '''$x
+foo''');
+
+  Expect.equals('foo', r'''  
+foo''');
+
+  Expect.equals('\\\\\nfoo', r'''\\
+foo''');
+
+  Expect.equals('\\t\nfoo', r'''\t
+foo''');
+
+  Expect.equals('foo', r'''\
+foo''');
+
+  Expect.equals('foo', r'''\ \
+foo''');
+}