Skip to content

Commit 739e784

Browse files
Clarify "string continue" for (byte) string literals
The previous version just said "whitespace at the beginning of the next line is ignored", but that is not quite correct. Currently, exactly four characters are ignored in that position. This is different from the definition of `char::is_whitespace` and `char::is_ascii_whitespace`. Additionally "at the beginning of the next line" is confusing as additional \n are also ignored. https://github.com/rust-lang/rust/blob/595088d602049d821bf9a217f2d79aea40715208/compiler/rustc_lexer/src/unescape.rs#L281-L287 https://github.com/rust-lang/rust/blob/595088d602049d821bf9a217f2d79aea40715208/compiler/rustc_lexer/src/unescape.rs#L300-L307
1 parent 8f598e2 commit 739e784

File tree

1 file changed

+9
-4
lines changed

1 file changed

+9
-4
lines changed

src/tokens.md

+9-4
Original file line numberDiff line numberDiff line change
@@ -153,16 +153,21 @@ which must be _escaped_ by a preceding `U+005C` character (`\`).
153153
Line-breaks are allowed in string literals. A line-break is either a newline
154154
(`U+000A`) or a pair of carriage return and newline (`U+000D`, `U+000A`). Both
155155
byte sequences are normally translated to `U+000A`, but as a special exception,
156-
when an unescaped `U+005C` character (`\`) occurs immediately before the
157-
line-break, then the `U+005C` character, the line-break, and all whitespace at the
158-
beginning of the next line are ignored. Thus `a` and `b` are equal:
156+
when an unescaped `U+005C` character (`\`) occurs immediately before a `\n`
157+
(`U+000A`), then the `U+005C` character, and all immediately following
158+
` ` (`U+0020`), `\t` (`U+0009`), `\n` (`U+000A`) and `\r` (`U+0000D`) characters
159+
are ignored. Thus `a`, `b` and `c` are equal:
159160

160161
```rust
161162
let a = "foobar";
162163
let b = "foo\
163164
bar";
165+
let c = "foo\
164166
165-
assert_eq!(a,b);
167+
bar";
168+
169+
assert_eq!(a, b);
170+
assert_eq!(b, c);
166171
```
167172

168173
#### Character escapes

0 commit comments

Comments
 (0)