mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
a94d4d57de
rust/tests/ui/parser/label-is-actually-char.stderr

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

94 lines
2.4 KiB
Plaintext
Raw Normal View History

Recover unclosed char literal being parsed as lifetime
2022-09-01 13:48:09 -05:00
error: expected `while`, `for`, `loop` or `{` after a label
Be more careful about interpreting a label/lifetime as a mistyped char literal. Currently the parser will interpret any label/lifetime in certain positions as a mistyped char literal, on the assumption that the trailing single quote was accidentally omitted. This is reasonable for a something like 'a (because 'a' would be valid) but not reasonable for a something like 'abc (because 'abc' is not valid). This commit restricts this behaviour only to labels/lifetimes that would be valid char literals, via the new `could_be_unclosed_char_literal` function. The commit also augments the `label-is-actually-char.rs` test in a couple of ways: - Adds testing of labels/lifetimes with identifiers longer than one char, e.g. 'abc. - Adds a new match with simpler patterns, because the `recover_unclosed_char` call in `parse_pat_with_range_pat` was not being exercised (in this test or any other ui tests). Fixes #120397, an assertion failure, which was caused by this behaviour in the parser interacting with some new stricter char literal checking added in #120329.
2024-01-28 16:47:02 -06:00
--> $DIR/label-is-actually-char.rs:5:15
Recover unclosed char literal being parsed as lifetime
2022-09-01 13:48:09 -05:00
|
LL | let c = 'a;
| ^ expected `while`, `for`, `loop` or `{` after a label
|
help: add `'` to close the char literal
|
LL | let c = 'a';
| +
Be more careful about interpreting a label/lifetime as a mistyped char literal. Currently the parser will interpret any label/lifetime in certain positions as a mistyped char literal, on the assumption that the trailing single quote was accidentally omitted. This is reasonable for a something like 'a (because 'a' would be valid) but not reasonable for a something like 'abc (because 'abc' is not valid). This commit restricts this behaviour only to labels/lifetimes that would be valid char literals, via the new `could_be_unclosed_char_literal` function. The commit also augments the `label-is-actually-char.rs` test in a couple of ways: - Adds testing of labels/lifetimes with identifiers longer than one char, e.g. 'abc. - Adds a new match with simpler patterns, because the `recover_unclosed_char` call in `parse_pat_with_range_pat` was not being exercised (in this test or any other ui tests). Fixes #120397, an assertion failure, which was caused by this behaviour in the parser interacting with some new stricter char literal checking added in #120329.
2024-01-28 16:47:02 -06:00
error: expected `while`, `for`, `loop` or `{` after a label
--> $DIR/label-is-actually-char.rs:9:17
|
LL | let c = 'abc;
| ^ expected `while`, `for`, `loop` or `{` after a label
error: expected expression, found `;`
--> $DIR/label-is-actually-char.rs:9:17
|
LL | let c = 'abc;
| ^ expected expression
Recover unclosed char literal being parsed as lifetime
2022-09-01 13:48:09 -05:00
error: unexpected token: `'b`
Be more careful about interpreting a label/lifetime as a mistyped char literal. Currently the parser will interpret any label/lifetime in certain positions as a mistyped char literal, on the assumption that the trailing single quote was accidentally omitted. This is reasonable for a something like 'a (because 'a' would be valid) but not reasonable for a something like 'abc (because 'abc' is not valid). This commit restricts this behaviour only to labels/lifetimes that would be valid char literals, via the new `could_be_unclosed_char_literal` function. The commit also augments the `label-is-actually-char.rs` test in a couple of ways: - Adds testing of labels/lifetimes with identifiers longer than one char, e.g. 'abc. - Adds a new match with simpler patterns, because the `recover_unclosed_char` call in `parse_pat_with_range_pat` was not being exercised (in this test or any other ui tests). Fixes #120397, an assertion failure, which was caused by this behaviour in the parser interacting with some new stricter char literal checking added in #120329.
2024-01-28 16:47:02 -06:00
--> $DIR/label-is-actually-char.rs:16:15
Recover unclosed char literal being parsed as lifetime
2022-09-01 13:48:09 -05:00
|
LL | 'a'..='b => {}
| ^^
|
help: add `'` to close the char literal
|
LL | 'a'..='b' => {}
| +
Be more careful about interpreting a label/lifetime as a mistyped char literal. Currently the parser will interpret any label/lifetime in certain positions as a mistyped char literal, on the assumption that the trailing single quote was accidentally omitted. This is reasonable for a something like 'a (because 'a' would be valid) but not reasonable for a something like 'abc (because 'abc' is not valid). This commit restricts this behaviour only to labels/lifetimes that would be valid char literals, via the new `could_be_unclosed_char_literal` function. The commit also augments the `label-is-actually-char.rs` test in a couple of ways: - Adds testing of labels/lifetimes with identifiers longer than one char, e.g. 'abc. - Adds a new match with simpler patterns, because the `recover_unclosed_char` call in `parse_pat_with_range_pat` was not being exercised (in this test or any other ui tests). Fixes #120397, an assertion failure, which was caused by this behaviour in the parser interacting with some new stricter char literal checking added in #120329.
2024-01-28 16:47:02 -06:00
error: unexpected token: `'def`
--> $DIR/label-is-actually-char.rs:19:15
|
LL | 'c'..='def => {}
| ^^^^
error: expected pattern, found `=>`
--> $DIR/label-is-actually-char.rs:26:11
|
LL | 'g => {}
| ^^ expected pattern
|
help: add `'` to close the char literal
|
LL | 'g' => {}
| +
error: expected pattern, found `'hij`
--> $DIR/label-is-actually-char.rs:29:8
|
LL | 'hij => {}
| ^^^^ expected pattern
Recover unclosed char literal being parsed as lifetime
2022-09-01 13:48:09 -05:00
error: expected `while`, `for`, `loop` or `{` after a label
Be more careful about interpreting a label/lifetime as a mistyped char literal. Currently the parser will interpret any label/lifetime in certain positions as a mistyped char literal, on the assumption that the trailing single quote was accidentally omitted. This is reasonable for a something like 'a (because 'a' would be valid) but not reasonable for a something like 'abc (because 'abc' is not valid). This commit restricts this behaviour only to labels/lifetimes that would be valid char literals, via the new `could_be_unclosed_char_literal` function. The commit also augments the `label-is-actually-char.rs` test in a couple of ways: - Adds testing of labels/lifetimes with identifiers longer than one char, e.g. 'abc. - Adds a new match with simpler patterns, because the `recover_unclosed_char` call in `parse_pat_with_range_pat` was not being exercised (in this test or any other ui tests). Fixes #120397, an assertion failure, which was caused by this behaviour in the parser interacting with some new stricter char literal checking added in #120329.
2024-01-28 16:47:02 -06:00
--> $DIR/label-is-actually-char.rs:36:15
Recover unclosed char literal being parsed as lifetime
2022-09-01 13:48:09 -05:00
|
Be more careful about interpreting a label/lifetime as a mistyped char literal. Currently the parser will interpret any label/lifetime in certain positions as a mistyped char literal, on the assumption that the trailing single quote was accidentally omitted. This is reasonable for a something like 'a (because 'a' would be valid) but not reasonable for a something like 'abc (because 'abc' is not valid). This commit restricts this behaviour only to labels/lifetimes that would be valid char literals, via the new `could_be_unclosed_char_literal` function. The commit also augments the `label-is-actually-char.rs` test in a couple of ways: - Adds testing of labels/lifetimes with identifiers longer than one char, e.g. 'abc. - Adds a new match with simpler patterns, because the `recover_unclosed_char` call in `parse_pat_with_range_pat` was not being exercised (in this test or any other ui tests). Fixes #120397, an assertion failure, which was caused by this behaviour in the parser interacting with some new stricter char literal checking added in #120329.
2024-01-28 16:47:02 -06:00
LL | let x = ['a, 'b, 'cde];
| ^ expected `while`, `for`, `loop` or `{` after a label
Recover unclosed char literal being parsed as lifetime
2022-09-01 13:48:09 -05:00
|
help: add `'` to close the char literal
|
Be more careful about interpreting a label/lifetime as a mistyped char literal. Currently the parser will interpret any label/lifetime in certain positions as a mistyped char literal, on the assumption that the trailing single quote was accidentally omitted. This is reasonable for a something like 'a (because 'a' would be valid) but not reasonable for a something like 'abc (because 'abc' is not valid). This commit restricts this behaviour only to labels/lifetimes that would be valid char literals, via the new `could_be_unclosed_char_literal` function. The commit also augments the `label-is-actually-char.rs` test in a couple of ways: - Adds testing of labels/lifetimes with identifiers longer than one char, e.g. 'abc. - Adds a new match with simpler patterns, because the `recover_unclosed_char` call in `parse_pat_with_range_pat` was not being exercised (in this test or any other ui tests). Fixes #120397, an assertion failure, which was caused by this behaviour in the parser interacting with some new stricter char literal checking added in #120329.
2024-01-28 16:47:02 -06:00
LL | let x = ['a', 'b, 'cde];
| +
Recover unclosed char literal being parsed as lifetime
2022-09-01 13:48:09 -05:00
error: expected `while`, `for`, `loop` or `{` after a label
Be more careful about interpreting a label/lifetime as a mistyped char literal. Currently the parser will interpret any label/lifetime in certain positions as a mistyped char literal, on the assumption that the trailing single quote was accidentally omitted. This is reasonable for a something like 'a (because 'a' would be valid) but not reasonable for a something like 'abc (because 'abc' is not valid). This commit restricts this behaviour only to labels/lifetimes that would be valid char literals, via the new `could_be_unclosed_char_literal` function. The commit also augments the `label-is-actually-char.rs` test in a couple of ways: - Adds testing of labels/lifetimes with identifiers longer than one char, e.g. 'abc. - Adds a new match with simpler patterns, because the `recover_unclosed_char` call in `parse_pat_with_range_pat` was not being exercised (in this test or any other ui tests). Fixes #120397, an assertion failure, which was caused by this behaviour in the parser interacting with some new stricter char literal checking added in #120329.
2024-01-28 16:47:02 -06:00
--> $DIR/label-is-actually-char.rs:36:19
Recover unclosed char literal being parsed as lifetime
2022-09-01 13:48:09 -05:00
|
Be more careful about interpreting a label/lifetime as a mistyped char literal. Currently the parser will interpret any label/lifetime in certain positions as a mistyped char literal, on the assumption that the trailing single quote was accidentally omitted. This is reasonable for a something like 'a (because 'a' would be valid) but not reasonable for a something like 'abc (because 'abc' is not valid). This commit restricts this behaviour only to labels/lifetimes that would be valid char literals, via the new `could_be_unclosed_char_literal` function. The commit also augments the `label-is-actually-char.rs` test in a couple of ways: - Adds testing of labels/lifetimes with identifiers longer than one char, e.g. 'abc. - Adds a new match with simpler patterns, because the `recover_unclosed_char` call in `parse_pat_with_range_pat` was not being exercised (in this test or any other ui tests). Fixes #120397, an assertion failure, which was caused by this behaviour in the parser interacting with some new stricter char literal checking added in #120329.
2024-01-28 16:47:02 -06:00
LL | let x = ['a, 'b, 'cde];
| ^ expected `while`, `for`, `loop` or `{` after a label
Recover unclosed char literal being parsed as lifetime
2022-09-01 13:48:09 -05:00
|
help: add `'` to close the char literal
|
Be more careful about interpreting a label/lifetime as a mistyped char literal. Currently the parser will interpret any label/lifetime in certain positions as a mistyped char literal, on the assumption that the trailing single quote was accidentally omitted. This is reasonable for a something like 'a (because 'a' would be valid) but not reasonable for a something like 'abc (because 'abc' is not valid). This commit restricts this behaviour only to labels/lifetimes that would be valid char literals, via the new `could_be_unclosed_char_literal` function. The commit also augments the `label-is-actually-char.rs` test in a couple of ways: - Adds testing of labels/lifetimes with identifiers longer than one char, e.g. 'abc. - Adds a new match with simpler patterns, because the `recover_unclosed_char` call in `parse_pat_with_range_pat` was not being exercised (in this test or any other ui tests). Fixes #120397, an assertion failure, which was caused by this behaviour in the parser interacting with some new stricter char literal checking added in #120329.
2024-01-28 16:47:02 -06:00
LL | let x = ['a, 'b', 'cde];
| +
error: expected `while`, `for`, `loop` or `{` after a label
--> $DIR/label-is-actually-char.rs:36:25
|
LL | let x = ['a, 'b, 'cde];
| ^ expected `while`, `for`, `loop` or `{` after a label
error: expected expression, found `]`
--> $DIR/label-is-actually-char.rs:36:25
|
LL | let x = ['a, 'b, 'cde];
| ^ expected expression
Recover unclosed char literal being parsed as lifetime
2022-09-01 13:48:09 -05:00
Be more careful about interpreting a label/lifetime as a mistyped char literal. Currently the parser will interpret any label/lifetime in certain positions as a mistyped char literal, on the assumption that the trailing single quote was accidentally omitted. This is reasonable for a something like 'a (because 'a' would be valid) but not reasonable for a something like 'abc (because 'abc' is not valid). This commit restricts this behaviour only to labels/lifetimes that would be valid char literals, via the new `could_be_unclosed_char_literal` function. The commit also augments the `label-is-actually-char.rs` test in a couple of ways: - Adds testing of labels/lifetimes with identifiers longer than one char, e.g. 'abc. - Adds a new match with simpler patterns, because the `recover_unclosed_char` call in `parse_pat_with_range_pat` was not being exercised (in this test or any other ui tests). Fixes #120397, an assertion failure, which was caused by this behaviour in the parser interacting with some new stricter char literal checking added in #120329.
2024-01-28 16:47:02 -06:00
error: aborting due to 11 previous errors
Recover unclosed char literal being parsed as lifetime
2022-09-01 13:48:09 -05:00
Reference in New Issue Copy Permalink