rust-lang/rust
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
51b51b51d7931da85280382a81c4dd80c73ca754
rust/tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.no_feature.stderr

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

1276 lines
43 KiB
Plaintext
Raw Normal View History

[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
error: expected expression, found `let` statement
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:33:9
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | if (let 0 = 1) {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
note: `let`s wrapped in parentheses are not supported in a context with let chains
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:33:9
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | if (let 0 = 1) {}
| ^^^^^^^^^
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:36:11
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | if (((let 0 = 1))) {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
note: `let`s wrapped in parentheses are not supported in a context with let chains
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:36:11
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | if (((let 0 = 1))) {}
| ^^^^^^^^^
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:39:9
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | if (let 0 = 1) && true {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
note: `let`s wrapped in parentheses are not supported in a context with let chains
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:39:9
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | if (let 0 = 1) && true {}
| ^^^^^^^^^
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:42:17
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | if true && (let 0 = 1) {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
note: `let`s wrapped in parentheses are not supported in a context with let chains
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:42:17
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | if true && (let 0 = 1) {}
| ^^^^^^^^^
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:45:9
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | if (let 0 = 1) && (let 0 = 1) {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
note: `let`s wrapped in parentheses are not supported in a context with let chains
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:45:9
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | if (let 0 = 1) && (let 0 = 1) {}
| ^^^^^^^^^
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:45:24
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | if (let 0 = 1) && (let 0 = 1) {}
| ^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
note: `let`s wrapped in parentheses are not supported in a context with let chains
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:45:24
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | if (let 0 = 1) && (let 0 = 1) {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:49:35
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | if let 0 = 1 && let 1 = 2 && (let 2 = 3 && let 3 = 4 && let 4 = 5) {}
| ^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
note: `let`s wrapped in parentheses are not supported in a context with let chains
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:49:35
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | if let 0 = 1 && let 1 = 2 && (let 2 = 3 && let 3 = 4 && let 4 = 5) {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:49:48
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | if let 0 = 1 && let 1 = 2 && (let 2 = 3 && let 3 = 4 && let 4 = 5) {}
| ^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
note: `let`s wrapped in parentheses are not supported in a context with let chains
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:49:35
Use expr parse restrictions for let expr parsing
2022-08-01 01:13:16 +00:00
|
LL | if let 0 = 1 && let 1 = 2 && (let 2 = 3 && let 3 = 4 && let 4 = 5) {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Use expr parse restrictions for let expr parsing
2022-08-01 01:13:16 +00:00
error: expected expression, found `let` statement
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:49:61
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | if let 0 = 1 && let 1 = 2 && (let 2 = 3 && let 3 = 4 && let 4 = 5) {}
| ^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
note: `let`s wrapped in parentheses are not supported in a context with let chains
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:49:35
Use expr parse restrictions for let expr parsing
2022-08-01 01:13:16 +00:00
|
LL | if let 0 = 1 && let 1 = 2 && (let 2 = 3 && let 3 = 4 && let 4 = 5) {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Use expr parse restrictions for let expr parsing
2022-08-01 01:13:16 +00:00
error: expected expression, found `let` statement
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:59:12
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | while (let 0 = 1) {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
note: `let`s wrapped in parentheses are not supported in a context with let chains
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:59:12
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | while (let 0 = 1) {}
| ^^^^^^^^^
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:62:14
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | while (((let 0 = 1))) {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
note: `let`s wrapped in parentheses are not supported in a context with let chains
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:62:14
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | while (((let 0 = 1))) {}
| ^^^^^^^^^
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:65:12
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | while (let 0 = 1) && true {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
note: `let`s wrapped in parentheses are not supported in a context with let chains
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:65:12
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | while (let 0 = 1) && true {}
| ^^^^^^^^^
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:68:20
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | while true && (let 0 = 1) {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
note: `let`s wrapped in parentheses are not supported in a context with let chains
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:68:20
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | while true && (let 0 = 1) {}
| ^^^^^^^^^
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:71:12
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | while (let 0 = 1) && (let 0 = 1) {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
note: `let`s wrapped in parentheses are not supported in a context with let chains
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:71:12
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | while (let 0 = 1) && (let 0 = 1) {}
| ^^^^^^^^^
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:71:27
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | while (let 0 = 1) && (let 0 = 1) {}
| ^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
note: `let`s wrapped in parentheses are not supported in a context with let chains
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:71:27
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | while (let 0 = 1) && (let 0 = 1) {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:75:38
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | while let 0 = 1 && let 1 = 2 && (let 2 = 3 && let 3 = 4 && let 4 = 5) {}
| ^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
note: `let`s wrapped in parentheses are not supported in a context with let chains
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:75:38
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | while let 0 = 1 && let 1 = 2 && (let 2 = 3 && let 3 = 4 && let 4 = 5) {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:75:51
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | while let 0 = 1 && let 1 = 2 && (let 2 = 3 && let 3 = 4 && let 4 = 5) {}
| ^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
note: `let`s wrapped in parentheses are not supported in a context with let chains
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:75:38
Use expr parse restrictions for let expr parsing
2022-08-01 01:13:16 +00:00
|
LL | while let 0 = 1 && let 1 = 2 && (let 2 = 3 && let 3 = 4 && let 4 = 5) {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Use expr parse restrictions for let expr parsing
2022-08-01 01:13:16 +00:00
error: expected expression, found `let` statement
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:75:64
Use expr parse restrictions for let expr parsing
2022-08-01 01:13:16 +00:00
|
LL | while let 0 = 1 && let 1 = 2 && (let 2 = 3 && let 3 = 4 && let 4 = 5) {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
note: `let`s wrapped in parentheses are not supported in a context with let chains
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:75:38
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | while let 0 = 1 && let 1 = 2 && (let 2 = 3 && let 3 = 4 && let 4 = 5) {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Use expr parse restrictions for let expr parsing
2022-08-01 01:13:16 +00:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:103:9
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | if &let 0 = 0 {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:106:9
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | if !let 0 = 0 {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:108:9
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | if *let 0 = 0 {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:110:9
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | if -let 0 = 0 {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:118:9
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | if (let 0 = 0)? {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:121:16
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | if true || let 0 = 0 {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
note: `||` operators are not supported in let chain expressions
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:121:13
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | if true || let 0 = 0 {}
| ^^
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:123:17
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | if (true || let 0 = 0) {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:125:25
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | if true && (true || let 0 = 0) {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:127:25
Use expr parse restrictions for let expr parsing
2022-08-01 01:13:16 +00:00
|
LL | if true || (true && let 0 = 0) {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Use expr parse restrictions for let expr parsing
2022-08-01 01:13:16 +00:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:131:12
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | if x = let 0 = 0 {}
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:134:15
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | if true..(let 0 = 0) {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:137:11
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | if ..(let 0 = 0) {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:139:9
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | if (let 0 = 0).. {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:143:8
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | if let Range { start: _, end: _ } = true..true && false {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:146:8
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | if let Range { start: _, end: _ } = true..true || false {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:152:8
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | if let Range { start: F, end } = F..|| true {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:158:8
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | if let Range { start: true, end } = t..&&false {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:162:19
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | if let true = let true = true {}
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:165:15
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
|
LL | if return let 0 = 0 {}
| ^^^
|
= note: only supported directly in conditions of `if` and `while` expressions
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:168:21
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
|
LL | loop { if break let 0 = 0 {} }
| ^^^
|
= note: only supported directly in conditions of `if` and `while` expressions
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:171:15
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
|
LL | if (match let 0 = 0 { _ => { false } }) {}
| ^^^
|
= note: only supported directly in conditions of `if` and `while` expressions
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:174:9
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
|
LL | if (let 0 = 0, false).1 {}
| ^^^^^^^^^
|
= note: only supported directly in conditions of `if` and `while` expressions
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:177:9
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
|
LL | if (let 0 = 0,) {}
| ^^^^^^^^^
|
= note: only supported directly in conditions of `if` and `while` expressions
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:181:13
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
|
LL | if (let 0 = 0).await {}
| ^^^^^^^^^
|
= note: only supported directly in conditions of `if` and `while` expressions
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:185:12
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
|
LL | if (|| let 0 = 0) {}
| ^^^
|
= note: only supported directly in conditions of `if` and `while` expressions
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:188:9
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
|
LL | if (let 0 = 0)() {}
| ^^^^^^^^^
|
= note: only supported directly in conditions of `if` and `while` expressions
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:194:12
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | while &let 0 = 0 {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:197:12
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | while !let 0 = 0 {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:199:12
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | while *let 0 = 0 {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:201:12
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | while -let 0 = 0 {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:209:12
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | while (let 0 = 0)? {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:212:19
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | while true || let 0 = 0 {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
note: `||` operators are not supported in let chain expressions
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:212:16
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | while true || let 0 = 0 {}
| ^^
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:214:20
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | while (true || let 0 = 0) {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:216:28
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | while true && (true || let 0 = 0) {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:218:28
Use expr parse restrictions for let expr parsing
2022-08-01 01:13:16 +00:00
|
LL | while true || (true && let 0 = 0) {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Use expr parse restrictions for let expr parsing
2022-08-01 01:13:16 +00:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:222:15
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | while x = let 0 = 0 {}
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:225:18
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | while true..(let 0 = 0) {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:228:14
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | while ..(let 0 = 0) {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:230:12
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | while (let 0 = 0).. {}
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:234:11
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | while let Range { start: _, end: _ } = true..true && false {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:237:11
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | while let Range { start: _, end: _ } = true..true || false {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:243:11
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | while let Range { start: F, end } = F..|| true {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:249:11
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | while let Range { start: true, end } = t..&&false {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:253:22
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | while let true = let true = true {}
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:256:18
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
|
LL | while return let 0 = 0 {}
| ^^^
|
= note: only supported directly in conditions of `if` and `while` expressions
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:259:39
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
|
LL | 'outer: loop { while break 'outer let 0 = 0 {} }
| ^^^
|
= note: only supported directly in conditions of `if` and `while` expressions
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:262:18
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
|
LL | while (match let 0 = 0 { _ => { false } }) {}
| ^^^
|
= note: only supported directly in conditions of `if` and `while` expressions
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:265:12
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
|
LL | while (let 0 = 0, false).1 {}
| ^^^^^^^^^
|
= note: only supported directly in conditions of `if` and `while` expressions
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:268:12
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
|
LL | while (let 0 = 0,) {}
| ^^^^^^^^^
|
= note: only supported directly in conditions of `if` and `while` expressions
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:272:16
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
|
LL | while (let 0 = 0).await {}
| ^^^^^^^^^
|
= note: only supported directly in conditions of `if` and `while` expressions
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:276:15
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
|
LL | while (|| let 0 = 0) {}
| ^^^
|
= note: only supported directly in conditions of `if` and `while` expressions
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:279:12
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
|
LL | while (let 0 = 0)() {}
| ^^^^^^^^^
|
= note: only supported directly in conditions of `if` and `while` expressions
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:296:6
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
|
LL | &let 0 = 0;
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:299:6
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
|
LL | !let 0 = 0;
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:301:6
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
|
LL | *let 0 = 0;
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:303:6
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
|
LL | -let 0 = 0;
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:305:13
Unify disallowed-positions test files into one file Also make the file have a third mode for where everything is cfg'd out to make sure it's an early error.
2024-11-09 22:55:20 +01:00
|
LL | let _ = let _ = 3;
| ^^^
|
= note: only supported directly in conditions of `if` and `while` expressions
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:313:6
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
|
LL | (let 0 = 0)?;
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:316:13
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
|
LL | true || let 0 = 0;
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:318:14
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
|
LL | (true || let 0 = 0);
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:320:22
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
|
LL | true && (true || let 0 = 0);
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:324:9
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
|
LL | x = let 0 = 0;
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:327:12
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
|
LL | true..(let 0 = 0);
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:329:8
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
|
LL | ..(let 0 = 0);
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:331:6
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
|
LL | (let 0 = 0)..;
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:334:6
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
|
LL | (let Range { start: _, end: _ } = true..true || false);
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:338:6
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
|
LL | (let true = let true = true);
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:338:17
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
|
LL | (let true = let true = true);
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:344:25
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
|
LL | let x = true && let y = 1;
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:350:19
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
|
LL | [1, 2, 3][let _ = ()]
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:355:6
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
|
LL | &let 0 = 0
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
Use expr parse restrictions for let expr parsing
2022-08-01 01:13:16 +00:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:366:17
Use expr parse restrictions for let expr parsing
2022-08-01 01:13:16 +00:00
|
LL | true && let 1 = 1
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Use expr parse restrictions for let expr parsing
2022-08-01 01:13:16 +00:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:371:17
Use expr parse restrictions for let expr parsing
2022-08-01 01:13:16 +00:00
|
LL | true && let 1 = 1
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Use expr parse restrictions for let expr parsing
2022-08-01 01:13:16 +00:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:376:17
Use expr parse restrictions for let expr parsing
2022-08-01 01:13:16 +00:00
|
LL | true && let 1 = 1
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Use expr parse restrictions for let expr parsing
2022-08-01 01:13:16 +00:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:387:17
Use expr parse restrictions for let expr parsing
2022-08-01 01:13:16 +00:00
|
LL | true && let 1 = 1
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Use expr parse restrictions for let expr parsing
2022-08-01 01:13:16 +00:00
Suggest expressions that look like const generic arguments should be enclosed in brackets Co-Authored-By: Esteban Kuber <github@kuber.com.ar>
2020-10-03 19:30:32 +01:00
error: expressions must be enclosed in braces to be used as const generic arguments
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:387:9
let_chains: Account for const generics in validation tests.
2019-05-21 06:50:53 +02:00
|
LL | true && let 1 = 1
Suggest expressions that look like const generic arguments should be enclosed in brackets Co-Authored-By: Esteban Kuber <github@kuber.com.ar>
2020-10-03 19:30:32 +01:00
| ^^^^^^^^^^^^^^^^^
|
help: enclose the `const` expression in braces
|
LL | { true && let 1 = 1 }
Modify structured suggestion output * On suggestions that include deletions, use a diff inspired output format * When suggesting addition, use `+` as underline * Color highlight modified span
2021-06-21 19:07:19 -07:00
| + +
let_chains: Account for const generics in validation tests.
2019-05-21 06:50:53 +02:00
[rustc_parse] Forbid lets in certain places
2022-06-25 08:08:38 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:397:9
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | if (let Some(a) = opt && true) {
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
note: `let`s wrapped in parentheses are not supported in a context with let chains
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:397:9
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | if (let Some(a) = opt && true) {
| ^^^^^^^^^^^^^^^^^^^^^^^^^
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:401:9
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | if (let Some(a) = opt) && true {
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
note: `let`s wrapped in parentheses are not supported in a context with let chains
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:401:9
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | if (let Some(a) = opt) && true {
| ^^^^^^^^^^^^^^^^^
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:404:9
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | if (let Some(a) = opt) && (let Some(b) = a) {
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
note: `let`s wrapped in parentheses are not supported in a context with let chains
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:404:9
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | if (let Some(a) = opt) && (let Some(b) = a) {
| ^^^^^^^^^^^^^^^^^
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:404:32
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | if (let Some(a) = opt) && (let Some(b) = a) {
| ^^^^^^^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
note: `let`s wrapped in parentheses are not supported in a context with let chains
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:404:32
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | if (let Some(a) = opt) && (let Some(b) = a) {
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^^^^^^^
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:412:9
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | if (let Some(a) = opt && (let Some(b) = a)) && b == 1 {
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
note: `let`s wrapped in parentheses are not supported in a context with let chains
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:412:9
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | if (let Some(a) = opt && (let Some(b) = a)) && b == 1 {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:412:31
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
|
LL | if (let Some(a) = opt && (let Some(b) = a)) && b == 1 {
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
| ^^^^^^^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
note: `let`s wrapped in parentheses are not supported in a context with let chains
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:412:31
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
|
LL | if (let Some(a) = opt && (let Some(b) = a)) && b == 1 {
| ^^^^^^^^^^^^^^^
Fix last let_chains blocker
2022-07-08 07:25:50 -03:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:416:9
[let_chains] Forbid let inside parentheses
2022-03-31 18:33:05 -03:00
|
LL | if (let Some(a) = opt && (let Some(b) = a)) && true {
| ^^^^^^^^^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
[let_chains] Forbid let inside parentheses
2022-03-31 18:33:05 -03:00
note: `let`s wrapped in parentheses are not supported in a context with let chains
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:416:9
[let_chains] Forbid let inside parentheses
2022-03-31 18:33:05 -03:00
|
LL | if (let Some(a) = opt && (let Some(b) = a)) && true {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:416:31
[let_chains] Forbid let inside parentheses
2022-03-31 18:33:05 -03:00
|
LL | if (let Some(a) = opt && (let Some(b) = a)) && true {
| ^^^^^^^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
[let_chains] Forbid let inside parentheses
2022-03-31 18:33:05 -03:00
note: `let`s wrapped in parentheses are not supported in a context with let chains
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:416:31
[let_chains] Forbid let inside parentheses
2022-03-31 18:33:05 -03:00
|
LL | if (let Some(a) = opt && (let Some(b) = a)) && true {
| ^^^^^^^^^^^^^^^
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:420:9
[let_chains] Forbid let inside parentheses
2022-03-31 18:33:05 -03:00
|
LL | if (let Some(a) = opt && (true)) && true {
| ^^^^^^^^^^^^^^^^^
|
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
= note: only supported directly in conditions of `if` and `while` expressions
[let_chains] Forbid let inside parentheses
2022-03-31 18:33:05 -03:00
note: `let`s wrapped in parentheses are not supported in a context with let chains
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:420:9
[let_chains] Forbid let inside parentheses
2022-03-31 18:33:05 -03:00
|
LL | if (let Some(a) = opt && (true)) && true {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
Suggest expressions that look like const generic arguments should be enclosed in brackets Co-Authored-By: Esteban Kuber <github@kuber.com.ar>
2020-10-03 19:30:32 +01:00
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:440:22
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
|
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
LL | let x = (true && let y = 1);
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:445:20
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
|
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
LL | ([1, 2, 3][let _ = ()])
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
error: expected expression, found `let` statement
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:91:16
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
|
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
LL | use_expr!((let 0 = 1 && 0 == 0));
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
error: expected expression, found `let` statement
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:91:16
|
LL | use_expr!((let 0 = 1 && 0 == 0));
| ^^^
|
= note: only supported directly in conditions of `if` and `while` expressions
= note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no`
error: expected expression, found `let` statement
--> $DIR/disallowed-positions.rs:91:16
|
LL | use_expr!((let 0 = 1 && 0 == 0));
| ^^^
|
= note: only supported directly in conditions of `if` and `while` expressions
= note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no`
error: expected expression, found `let` statement
--> $DIR/disallowed-positions.rs:95:16
|
LL | use_expr!((let 0 = 1));
| ^^^
|
= note: only supported directly in conditions of `if` and `while` expressions
error: expected expression, found `let` statement
--> $DIR/disallowed-positions.rs:95:16
|
LL | use_expr!((let 0 = 1));
| ^^^
|
= note: only supported directly in conditions of `if` and `while` expressions
= note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no`
error: expected expression, found `let` statement
--> $DIR/disallowed-positions.rs:95:16
Suggest `if let x = y` when encountering `if x = y` Detect potential cases where `if let` was meant but `let` was left out. Fix #44990.
2020-08-25 20:28:25 -07:00
|
Move let expression checking to parsing There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-08 10:14:36 +00:00
LL | use_expr!((let 0 = 1));
| ^^^
Address review comments - Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-13 15:00:31 +00:00
|
= note: only supported directly in conditions of `if` and `while` expressions
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
= note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
Unify disallowed-positions test files into one file Also make the file have a third mode for where everything is cfg'd out to make sure it's an early error.
2024-11-09 22:55:20 +01:00
error[E0658]: `let` expressions in this position are unstable
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:49:8
Unify disallowed-positions test files into one file Also make the file have a third mode for where everything is cfg'd out to make sure it's an early error.
2024-11-09 22:55:20 +01:00
|
LL | if let 0 = 1 && let 1 = 2 && (let 2 = 3 && let 3 = 4 && let 4 = 5) {}
| ^^^^^^^^^
|
= note: see issue #53667 <https://github.com/rust-lang/rust/issues/53667> for more information
= help: add `#![feature(let_chains)]` to the crate attributes to enable
= note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date
error[E0658]: `let` expressions in this position are unstable
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:49:21
Unify disallowed-positions test files into one file Also make the file have a third mode for where everything is cfg'd out to make sure it's an early error.
2024-11-09 22:55:20 +01:00
|
LL | if let 0 = 1 && let 1 = 2 && (let 2 = 3 && let 3 = 4 && let 4 = 5) {}
| ^^^^^^^^^
|
= note: see issue #53667 <https://github.com/rust-lang/rust/issues/53667> for more information
= help: add `#![feature(let_chains)]` to the crate attributes to enable
= note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date
error[E0658]: `let` expressions in this position are unstable
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:75:11
Unify disallowed-positions test files into one file Also make the file have a third mode for where everything is cfg'd out to make sure it's an early error.
2024-11-09 22:55:20 +01:00
|
LL | while let 0 = 1 && let 1 = 2 && (let 2 = 3 && let 3 = 4 && let 4 = 5) {}
| ^^^^^^^^^
|
= note: see issue #53667 <https://github.com/rust-lang/rust/issues/53667> for more information
= help: add `#![feature(let_chains)]` to the crate attributes to enable
= note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date
error[E0658]: `let` expressions in this position are unstable
Add more places where expressions can occur
2024-11-09 23:31:11 +01:00
--> $DIR/disallowed-positions.rs:75:24
Unify disallowed-positions test files into one file Also make the file have a third mode for where everything is cfg'd out to make sure it's an early error.
2024-11-09 22:55:20 +01:00
|
LL | while let 0 = 1 && let 1 = 2 && (let 2 = 3 && let 3 = 4 && let 4 = 5) {}
| ^^^^^^^^^
|
= note: see issue #53667 <https://github.com/rust-lang/rust/issues/53667> for more information
= help: add `#![feature(let_chains)]` to the crate attributes to enable
= note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date
error[E0658]: `let` expressions in this position are unstable
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:408:8
Unify disallowed-positions test files into one file Also make the file have a third mode for where everything is cfg'd out to make sure it's an early error.
2024-11-09 22:55:20 +01:00
|
LL | if let Some(a) = opt && (true && true) {
| ^^^^^^^^^^^^^^^^^
|
= note: see issue #53667 <https://github.com/rust-lang/rust/issues/53667> for more information
= help: add `#![feature(let_chains)]` to the crate attributes to enable
= note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date
error[E0658]: `let` expressions in this position are unstable
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:424:28
Unify disallowed-positions test files into one file Also make the file have a third mode for where everything is cfg'd out to make sure it's an early error.
2024-11-09 22:55:20 +01:00
|
LL | if (true && (true)) && let Some(a) = opt {
| ^^^^^^^^^^^^^^^^^
|
= note: see issue #53667 <https://github.com/rust-lang/rust/issues/53667> for more information
= help: add `#![feature(let_chains)]` to the crate attributes to enable
= note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date
error[E0658]: `let` expressions in this position are unstable
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:427:18
Unify disallowed-positions test files into one file Also make the file have a third mode for where everything is cfg'd out to make sure it's an early error.
2024-11-09 22:55:20 +01:00
|
LL | if (true) && let Some(a) = opt {
| ^^^^^^^^^^^^^^^^^
|
= note: see issue #53667 <https://github.com/rust-lang/rust/issues/53667> for more information
= help: add `#![feature(let_chains)]` to the crate attributes to enable
= note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date
error[E0658]: `let` expressions in this position are unstable
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:430:16
Unify disallowed-positions test files into one file Also make the file have a third mode for where everything is cfg'd out to make sure it's an early error.
2024-11-09 22:55:20 +01:00
|
LL | if true && let Some(a) = opt {
| ^^^^^^^^^^^^^^^^^
|
= note: see issue #53667 <https://github.com/rust-lang/rust/issues/53667> for more information
= help: add `#![feature(let_chains)]` to the crate attributes to enable
= note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date
error[E0658]: `let` expressions in this position are unstable
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:435:8
Unify disallowed-positions test files into one file Also make the file have a third mode for where everything is cfg'd out to make sure it's an early error.
2024-11-09 22:55:20 +01:00
|
LL | if let true = (true && fun()) && (true) {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #53667 <https://github.com/rust-lang/rust/issues/53667> for more information
= help: add `#![feature(let_chains)]` to the crate attributes to enable
= note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
error[E0308]: mismatched types
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:134:8
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
|
LL | if true..(let 0 = 0) {}
Modify primary span label for E0308 The previous output was unintuitive to users.
2023-01-02 18:00:33 -08:00
| ^^^^^^^^^^^^^^^^^ expected `bool`, found `Range<bool>`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
|
= note: expected type `bool`
Specific labels when referring to "expected" and "found" types
2019-11-13 14:16:56 -08:00
found struct `std::ops::Range<bool>`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
error[E0308]: mismatched types
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:143:12
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
|
LL | if let Range { start: _, end: _ } = true..true && false {}
MatchExpressionArmPattern: Use more generic wording. The existing wording was inappropriate for e.g. `if let Ok(_) = expr { .. }`. The diagnostic would leak the fact that we desugar to a `match`.
2019-12-30 07:02:24 +01:00
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ ---- this expression has type `bool`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
| |
Modify primary span label for E0308 The previous output was unintuitive to users.
2023-01-02 18:00:33 -08:00
| expected `bool`, found `Range<_>`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
|
= note: expected type `bool`
Specific labels when referring to "expected" and "found" types
2019-11-13 14:16:56 -08:00
found struct `std::ops::Range<_>`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
error[E0308]: mismatched types
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:146:12
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
|
LL | if let Range { start: _, end: _ } = true..true || false {}
MatchExpressionArmPattern: Use more generic wording. The existing wording was inappropriate for e.g. `if let Ok(_) = expr { .. }`. The diagnostic would leak the fact that we desugar to a `match`.
2019-12-30 07:02:24 +01:00
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ ---- this expression has type `bool`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
| |
Modify primary span label for E0308 The previous output was unintuitive to users.
2023-01-02 18:00:33 -08:00
| expected `bool`, found `Range<_>`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
|
= note: expected type `bool`
Specific labels when referring to "expected" and "found" types
2019-11-13 14:16:56 -08:00
found struct `std::ops::Range<_>`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
error[E0308]: mismatched types
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:152:12
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
|
LL | if let Range { start: F, end } = F..|| true {}
Make TyS::is_suggestable more structual
2021-12-13 21:22:02 -08:00
| ^^^^^^^^^^^^^^^^^^^^^^^ - this expression has type `fn() -> bool`
| |
Modify primary span label for E0308 The previous output was unintuitive to users.
2023-01-02 18:00:33 -08:00
| expected fn pointer, found `Range<_>`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
|
Specific labels when referring to "expected" and "found" types
2019-11-13 14:16:56 -08:00
= note: expected fn pointer `fn() -> bool`
found struct `std::ops::Range<_>`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
error[E0308]: mismatched types
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:158:12
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
|
LL | if let Range { start: true, end } = t..&&false {}
refactor and fix this-expression-has-type note
2019-12-30 09:08:18 +01:00
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ - this expression has type `&&bool`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
| |
Modify primary span label for E0308 The previous output was unintuitive to users.
2023-01-02 18:00:33 -08:00
| expected `bool`, found `Range<_>`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
|
= note: expected type `bool`
Specific labels when referring to "expected" and "found" types
2019-11-13 14:16:56 -08:00
found struct `std::ops::Range<_>`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
pretty: trim paths of unique symbols If a symbol name can only be imported from one place for a type, and as long as it was not glob-imported anywhere in the current crate, we can trim its printed path and print only the name. This has wide implications on error messages with types, for example, shortening `std::vec::Vec` to just `Vec`, as long as there is no other `Vec` importable anywhere. This adds a new '-Z trim-diagnostic-paths=false' option to control this feature. On the good path, with no diagnosis printed, we should try to avoid issuing this query, so we need to prevent trimmed_def_paths query on several cases. This change also relies on a previous commit that differentiates between `Debug` and `Display` on various rustc types, where the latter is trimmed and presented to the user and the former is not.
2020-09-02 10:40:56 +03:00
error[E0277]: the `?` operator can only be applied to values that implement `Try`
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:114:20
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
|
LL | if let 0 = 0? {}
| ^^ the `?` operator cannot be applied to type `{integer}`
|
pretty: trim paths of unique symbols If a symbol name can only be imported from one place for a type, and as long as it was not glob-imported anywhere in the current crate, we can trim its printed path and print only the name. This has wide implications on error messages with types, for example, shortening `std::vec::Vec` to just `Vec`, as long as there is no other `Vec` importable anywhere. This adds a new '-Z trim-diagnostic-paths=false' option to control this feature. On the good path, with no diagnosis printed, we should try to avoid issuing this query, so we need to prevent trimmed_def_paths query on several cases. This change also relies on a previous commit that differentiates between `Debug` and `Display` on various rustc types, where the latter is trimmed and presented to the user and the former is not.
2020-09-02 10:40:56 +03:00
= help: the trait `Try` is not implemented for `{integer}`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
error[E0308]: mismatched types
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:225:11
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
|
LL | while true..(let 0 = 0) {}
Modify primary span label for E0308 The previous output was unintuitive to users.
2023-01-02 18:00:33 -08:00
| ^^^^^^^^^^^^^^^^^ expected `bool`, found `Range<bool>`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
|
= note: expected type `bool`
Specific labels when referring to "expected" and "found" types
2019-11-13 14:16:56 -08:00
found struct `std::ops::Range<bool>`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
error[E0308]: mismatched types
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:234:15
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
|
LL | while let Range { start: _, end: _ } = true..true && false {}
MatchExpressionArmPattern: Use more generic wording. The existing wording was inappropriate for e.g. `if let Ok(_) = expr { .. }`. The diagnostic would leak the fact that we desugar to a `match`.
2019-12-30 07:02:24 +01:00
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ ---- this expression has type `bool`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
| |
Modify primary span label for E0308 The previous output was unintuitive to users.
2023-01-02 18:00:33 -08:00
| expected `bool`, found `Range<_>`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
|
= note: expected type `bool`
Specific labels when referring to "expected" and "found" types
2019-11-13 14:16:56 -08:00
found struct `std::ops::Range<_>`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
error[E0308]: mismatched types
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:237:15
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
|
LL | while let Range { start: _, end: _ } = true..true || false {}
MatchExpressionArmPattern: Use more generic wording. The existing wording was inappropriate for e.g. `if let Ok(_) = expr { .. }`. The diagnostic would leak the fact that we desugar to a `match`.
2019-12-30 07:02:24 +01:00
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ ---- this expression has type `bool`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
| |
Modify primary span label for E0308 The previous output was unintuitive to users.
2023-01-02 18:00:33 -08:00
| expected `bool`, found `Range<_>`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
|
= note: expected type `bool`
Specific labels when referring to "expected" and "found" types
2019-11-13 14:16:56 -08:00
found struct `std::ops::Range<_>`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
error[E0308]: mismatched types
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:243:15
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
|
LL | while let Range { start: F, end } = F..|| true {}
Make TyS::is_suggestable more structual
2021-12-13 21:22:02 -08:00
| ^^^^^^^^^^^^^^^^^^^^^^^ - this expression has type `fn() -> bool`
| |
Modify primary span label for E0308 The previous output was unintuitive to users.
2023-01-02 18:00:33 -08:00
| expected fn pointer, found `Range<_>`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
|
Specific labels when referring to "expected" and "found" types
2019-11-13 14:16:56 -08:00
= note: expected fn pointer `fn() -> bool`
found struct `std::ops::Range<_>`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
error[E0308]: mismatched types
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:249:15
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
|
LL | while let Range { start: true, end } = t..&&false {}
refactor and fix this-expression-has-type note
2019-12-30 09:08:18 +01:00
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ - this expression has type `&&bool`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
| |
Modify primary span label for E0308 The previous output was unintuitive to users.
2023-01-02 18:00:33 -08:00
| expected `bool`, found `Range<_>`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
|
= note: expected type `bool`
Specific labels when referring to "expected" and "found" types
2019-11-13 14:16:56 -08:00
found struct `std::ops::Range<_>`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
pretty: trim paths of unique symbols If a symbol name can only be imported from one place for a type, and as long as it was not glob-imported anywhere in the current crate, we can trim its printed path and print only the name. This has wide implications on error messages with types, for example, shortening `std::vec::Vec` to just `Vec`, as long as there is no other `Vec` importable anywhere. This adds a new '-Z trim-diagnostic-paths=false' option to control this feature. On the good path, with no diagnosis printed, we should try to avoid issuing this query, so we need to prevent trimmed_def_paths query on several cases. This change also relies on a previous commit that differentiates between `Debug` and `Display` on various rustc types, where the latter is trimmed and presented to the user and the former is not.
2020-09-02 10:40:56 +03:00
error[E0277]: the `?` operator can only be applied to values that implement `Try`
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:205:23
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
|
LL | while let 0 = 0? {}
| ^^ the `?` operator cannot be applied to type `{integer}`
|
pretty: trim paths of unique symbols If a symbol name can only be imported from one place for a type, and as long as it was not glob-imported anywhere in the current crate, we can trim its printed path and print only the name. This has wide implications on error messages with types, for example, shortening `std::vec::Vec` to just `Vec`, as long as there is no other `Vec` importable anywhere. This adds a new '-Z trim-diagnostic-paths=false' option to control this feature. On the good path, with no diagnosis printed, we should try to avoid issuing this query, so we need to prevent trimmed_def_paths query on several cases. This change also relies on a previous commit that differentiates between `Debug` and `Display` on various rustc types, where the latter is trimmed and presented to the user and the former is not.
2020-09-02 10:40:56 +03:00
= help: the trait `Try` is not implemented for `{integer}`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
error[E0308]: mismatched types
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:334:10
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
|
LL | (let Range { start: _, end: _ } = true..true || false);
MatchExpressionArmPattern: Use more generic wording. The existing wording was inappropriate for e.g. `if let Ok(_) = expr { .. }`. The diagnostic would leak the fact that we desugar to a `match`.
2019-12-30 07:02:24 +01:00
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ ---- this expression has type `bool`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
| |
Modify primary span label for E0308 The previous output was unintuitive to users.
2023-01-02 18:00:33 -08:00
| expected `bool`, found `Range<_>`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
|
= note: expected type `bool`
Specific labels when referring to "expected" and "found" types
2019-11-13 14:16:56 -08:00
found struct `std::ops::Range<_>`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
pretty: trim paths of unique symbols If a symbol name can only be imported from one place for a type, and as long as it was not glob-imported anywhere in the current crate, we can trim its printed path and print only the name. This has wide implications on error messages with types, for example, shortening `std::vec::Vec` to just `Vec`, as long as there is no other `Vec` importable anywhere. This adds a new '-Z trim-diagnostic-paths=false' option to control this feature. On the good path, with no diagnosis printed, we should try to avoid issuing this query, so we need to prevent trimmed_def_paths query on several cases. This change also relies on a previous commit that differentiates between `Debug` and `Display` on various rustc types, where the latter is trimmed and presented to the user and the former is not.
2020-09-02 10:40:56 +03:00
error[E0277]: the `?` operator can only be applied to values that implement `Try`
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
--> $DIR/disallowed-positions.rs:309:17
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
|
LL | let 0 = 0?;
| ^^ the `?` operator cannot be applied to type `{integer}`
|
pretty: trim paths of unique symbols If a symbol name can only be imported from one place for a type, and as long as it was not glob-imported anywhere in the current crate, we can trim its printed path and print only the name. This has wide implications on error messages with types, for example, shortening `std::vec::Vec` to just `Vec`, as long as there is no other `Vec` importable anywhere. This adds a new '-Z trim-diagnostic-paths=false' option to control this feature. On the good path, with no diagnosis printed, we should try to avoid issuing this query, so we need to prevent trimmed_def_paths query on several cases. This change also relies on a previous commit that differentiates between `Debug` and `Display` on various rustc types, where the latter is trimmed and presented to the user and the former is not.
2020-09-02 10:40:56 +03:00
= help: the trait `Try` is not implemented for `{integer}`
let_chains: --bless tests due to recovery in lowering.
2019-06-17 07:38:26 +02:00
Remove `NtExpr` and `NtLiteral`. Notes about tests: - tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are now duplicated due to repeated parsing. - tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto. - `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large but the only difference is the insertion of a single invisible-delimited group around a metavar. - `tests/ui/attributes/nonterminal-expansion.rs`: a slight span degradation, somehow related to the recent massive attr parsing rewrite (#135726). I couldn't work out exactly what is going wrong, but I don't think it's worth holding things up for a single slightly suboptimal error message.
2024-04-18 21:31:17 +10:00
error: aborting due to 134 previous errors
let_chains: Add tests for places where let expressions aren't allowed.
2019-05-11 15:06:36 +02:00
Unify disallowed-positions test files into one file Also make the file have a third mode for where everything is cfg'd out to make sure it's an early error.
2024-11-09 22:55:20 +01:00
Some errors have detailed explanations: E0277, E0308, E0658.
Bless less verbose error messages The MIR const-checker errors for if/match/loop are now delay span bugs, so nothing will be emitted unless the HIR checker misses something.
2019-11-09 09:29:57 -08:00
For more information about an error, try `rustc --explain E0277`.
Reference in New Issue Copy Permalink