Commit graph

14 commits

Author SHA1 Message Date
Sasha Pourcelot
b21425de3c Emit proper errors on missing closure braces
This commit focuses on emitting clean errors for the following syntax
error:

```
Some(42).map(|a|
    dbg!(a);
    a
);
```

Previous implementation tried to recover after parsing the closure body
(the `dbg` expression) by replacing the next `;` with a `,`, which made
the next expression belong to the next function argument. As such, the
following errors were emitted (among others):
  - the semicolon token was not expected,
  - a is not in scope,
  - Option::map is supposed to take one argument, not two.

This commit allows us to gracefully handle this situation by adding
giving the parser the ability to remember when it has just parsed a
closure body inside a function call. When this happens, we can treat the
unexpected `;` specifically and try to parse as much statements as
possible in order to eat the whole block. When we can't parse statements
anymore, we generate a clean error indicating that the braces are
missing, and return an ExprKind::Err.
2021-09-09 17:44:40 +02:00
Caio
6aa9937a76 Introduce hir::ExprKind::Let - Take 2 2021-08-15 16:18:26 -03:00
Esteban Küber
99f2977031 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-08-11 09:46:24 +00:00
Esteban Küber
0b8f192cfe Use multispan suggestions more often
* Use more accurate span for `async move` suggestion
* Use more accurate span for deref suggestion
* Use `multipart_suggestion` more often
2021-07-30 09:26:31 -07:00
Aaron Hill
0dd9f118d9
Show macro name in 'this error originates in macro' message
When there are multiple macros in use, it can be difficult to tell
which one was responsible for producing an error.
2021-05-12 19:03:06 -04:00
Camelid
5d2a2a1caa Add explanations and suggestions to irrefutable_let_patterns lint 2021-02-18 16:21:16 -08:00
Dylan DPC
b3d3251271
Rollup merge of #82215 - TaKO8Ki:replace-if-let-while-let, r=varkor
Replace if-let and while-let with `if let` and `while let`

This pull request replaces if-let and while-let with `if let` and `while let`.

closes https://github.com/rust-lang/rust/issues/82205
2021-02-18 16:57:37 +01:00
Takayuki Maeda
0f04875d2e replace if-let and while-let with if let and while let 2021-02-17 19:26:38 +09:00
Caio
e7e93717ce Move some tests to more reasonable directories 2021-02-16 21:22:21 -03:00
Aleksey Kladov
356ea6b5aa Move format machinery tests to where they belong 2020-12-04 16:22:36 +03:00
Havvy (Ryan Scheel)
6919a775c6 Move src/test/ui/if-*.rs to src/test/expr/if/if-*.rs 2020-11-24 17:53:39 -08:00
Havvy (Ryan Scheel)
011bef8a84 Move src/test/ui/if-attrs to src/test/ui/expr/if/attrs 2020-11-24 17:37:15 -08:00
Havvy (Ryan Scheel)
37b97f095c Move src/test/ui/if to src/test/ui/expr/if 2020-11-24 17:35:53 -08:00
Havvy (Ryan Scheel)
b6f9705804 Add test for eval order for a+=b
Yes, the order of evaluation *does* change depending on the types of
the operands. Cursed, I know.

I've elected to place this test into `expr/compound-assignment` creating
both the `expr` directory and the `compound-assignment` directory. I
plan in a future PR to also move the `if` directory and the loose `if`
tests into `expr/if` and other similar cleanups of the `test/ui`
directory.

Future work: Test more than just `+=`, but all operators. I don't know
if using a macro to generate these tests cases would be okay or not,
but it'd be boilerplatey without it. I'm also confident you cannot
change the evaluation order of one operator without changing all of
them.

Future work: Additionally, test more than just `i32 += i32` for the
primitive version. I don't actually know the full set of primitive
implementations, but I imagine there's enough to cause a combinatorial
explosion with the previous future work item. Somewhere on the order of
one to two hundred individual functions.
2020-11-22 03:13:27 -08:00