about summary refs log tree commit diff
path: root/tests/ui/expr/if
AgeCommit message (Collapse)AuthorLines
2023-11-28Suggest `let` or `==` on typo'd let-chainEsteban Küber-10/+15
When encountering a bare assignment in a let-chain, suggest turning the assignment into a `let` expression or an equality check. ``` error: expected expression, found `let` statement --> $DIR/bad-if-let-suggestion.rs:5:8 | LL | if let x = 1 && i = 2 {} | ^^^^^^^^^ | = note: only supported directly in conditions of `if` and `while` expressions help: you might have meant to continue the let-chain | LL | if let x = 1 && let i = 2 {} | +++ help: you might have meant to compare for equality | LL | if let x = 1 && i == 2 {} | + ```
2023-11-24Show number in error message even for one errorNilstrieb-8/+8
Co-authored-by: Adrian <adrian.iosdev@gmail.com>
2023-09-13Address review commentsMatthew Jasper-0/+2
- 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-11Reduce double errors for invalid let expressionsMatthew Jasper-16/+6
Previously some invalid let expressions would result in both a feature error and a parsing error. Avoid this and ensure that we only emit the parsing error when this happens.
2023-09-11Move let expression checking to parsingMatthew Jasper-4/+2
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-01-11Move /src/test to /testsAlbert Larsan-0/+1124