Commit graph

81 commits

Author SHA1 Message Date
Oli Scherer
0978f6e010 Avoid silencing relevant follow-up errors 2024-01-09 21:08:16 +00:00
bors
5113ed28ea Auto merge of #118297 - shepmaster:warn-dead-tuple-fields, r=WaffleLapkin
Merge `unused_tuple_struct_fields` into `dead_code`

This implicitly upgrades the lint from `allow` to `warn` and places it into the `unused` lint group.

[Discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Moving.20.60unused_tuple_struct_fields.60.20from.20allow.20to.20warn)
2024-01-05 04:51:55 +00:00
Vadim Petrochenkov
e1d12c8caf macro_rules: Less hacky heuristic for using tt metavariable spans 2024-01-04 03:53:56 +03:00
Jake Goulding
53eca9fa87 Adjust compiler tests for unused_tuple_struct_fields -> dead_code 2024-01-02 15:34:37 -05:00
Lieselotte
7d6cd6bf1f
Don't expect bodyless arms if the pattern can never be a never pattern 2023-12-28 15:02:17 +01:00
Nicholas Nethercote
226edf64fa Improve an error involving attribute values.
Attribute values must be literals. The error you get when that doesn't
hold is pretty bad, e.g.:
```
unexpected expression: 1 + 1
```
You also get the same error if the attribute value is a literal, but an
invalid literal, e.g.:
```
unexpected expression: "foo"suffix
```

This commit does two things.
- Changes the error message to "attribute value must be a literal",
  which gives a better idea of what the problem is and how to fix it. It
  also no longer prints the invalid expression, because the carets below
  highlight it anyway.
- Separates the "not a literal" case from the "invalid literal" case.
  Which means invalid literals now get the specific error at the literal
  level, rather than at the attribute level.
2023-12-12 15:54:25 +11:00
bors
2b399b5275 Auto merge of #118527 - Nadrieril:never_patterns_parse, r=compiler-errors
never_patterns: Parse match arms with no body

Never patterns are meant to signal unreachable cases, and thus don't take bodies:
```rust
let ptr: *const Option<!> = ...;
match *ptr {
    None => { foo(); }
    Some(!),
}
```
This PR makes rustc accept the above, and enforces that an arm has a body xor is a never pattern. This affects parsing of match arms even with the feature off, so this is delicate. (Plus this is my first non-trivial change to the parser).

~~The last commit is optional; it introduces a bit of churn to allow the new suggestions to be machine-applicable. There may be a better solution? I'm not sure.~~ EDIT: I removed that commit

r? `@compiler-errors`
2023-12-08 17:08:52 +00:00
Nadrieril
80bdcbf50a Parse a pattern with no arm 2023-12-03 12:25:46 +01:00
bors
225e36cff9 Auto merge of #118542 - chenyukang:yukang-fix-parser-ice-118531, r=cjgillot
Fix parser ICE from attrs

Fixes #118531,
Fixes #118530.
2023-12-03 03:05:17 +00:00
yukang
5ff428c1ff Fix parser ICE from attrs 2023-12-02 23:47:39 +08:00
Esteban Küber
4e524386e9 Always emit help when failing to parse enum variant 2023-11-29 18:47:32 +00:00
Esteban Küber
bd1feb8cef Fix test and move to more appropriate directory 2023-11-29 18:47:32 +00:00
Esteban Küber
db39068ad7 Change enum parse recovery 2023-11-29 18:47:31 +00:00
Esteban Küber
1994abed74 Bubble parse error when expecting ) 2023-11-29 18:47:31 +00:00
Esteban Küber
44fd3b4d46 Make parse_pat_ident not recover bad name 2023-11-29 18:47:31 +00:00
Nilstrieb
41e8d152dc Show number in error message even for one error
Co-authored-by: Adrian <adrian.iosdev@gmail.com>
2023-11-24 19:15:52 +01:00
Matthias Krüger
ca3a02836e
Rollup merge of #117338 - workingjubilee:asmjs-meets-thanatos, r=b-naber
Remove asmjs

Fulfills [MCP 668](https://github.com/rust-lang/compiler-team/issues/668).

`asmjs-unknown-emscripten` does not work as-specified, and lacks essential upstream support for generating asm.js, so it should not exist at all.
2023-11-17 23:04:21 +01:00
Matthias Krüger
a5d7f8bcf2
Rollup merge of #117990 - estebank:issue-100825-part-deux, r=Nilstrieb
Tweak error and move tests

r? `@Nilstrieb`

Split off #117565.
2023-11-17 00:41:24 +01:00
Esteban Küber
1c6bd0b12b Smaller span for unnessary mut suggestion 2023-11-16 16:58:41 +00:00
Esteban Küber
f830fe313b Detect more => typos
Handle and recover `match expr { pat >= { arm } }`.
2023-11-14 00:46:37 +00:00
Guillaume Gomez
c828371179
Rollup merge of #117282 - clubby789:recover-wrong-function-header, r=TaKO8Ki
Recover from incorrectly ordered/duplicated function keywords

Fixes #115714
2023-11-08 17:14:36 +01:00
bors
187d1afa9d Auto merge of #117297 - clubby789:fn-trait-missing-paren, r=TaKO8Ki
Give a better diagnostic for missing parens in Fn* bounds

Fixes #108109

It would be nice to try and recover here, but I'm not sure it's worth the effort, especially as the bounds on the recovered function would be incorrect.
2023-11-07 13:04:56 +00:00
clubby789
904aceec7d Give a better diagnostic for missing parens in Fn* bounds 2023-11-01 15:33:46 +00:00
clubby789
ca1bcb6466 Recover from missing param list in function definitions 2023-11-01 14:48:20 +00:00
Jubilee Young
e9a009fd1a Remove asmjs from tests 2023-10-28 23:11:03 -07:00
clubby789
be0b42fabe Recover from incorrectly ordered/duplicated function keywords 2023-10-27 18:29:43 +00:00
Esteban Küber
855444ec54 mv tests 2023-10-24 21:27:05 +00:00
Esteban Küber
6b2c6c7fd3 Detect ruby-style closure in parser
When parsing a closure without a body that is surrounded by a block,
suggest moving the opening brace after the closure head.

Fix #116608.
2023-10-12 21:50:18 +00:00
Jubilee
0d68e416a5
Rollup merge of #116400 - estebank:issue-78585, r=WaffleLapkin
Detect missing `=>` after match guard during parsing

```
error: expected one of `,`, `:`, or `}`, found `.`
  --> $DIR/missing-fat-arrow.rs:25:14
   |
LL |         Some(a) if a.value == b {
   |                               - while parsing this struct
LL |             a.value = 1;
   |             -^ expected one of `,`, `:`, or `}`
   |             |
   |             while parsing this struct field
   |
help: try naming a field
   |
LL |             a: a.value = 1;
   |             ++
help: you might have meant to start a match arm after the match guard
   |
LL |         Some(a) if a.value == b => {
   |                                 ++
```

Fix #78585.
2023-10-06 16:37:47 -07:00
Alex Macleod
5453a9f34d Add a note to duplicate diagnostics 2023-10-05 01:04:41 +00:00
Esteban Küber
745c1ea438 Detect missing => after match guard during parsing
```
error: expected one of `,`, `:`, or `}`, found `.`
  --> $DIR/missing-fat-arrow.rs:25:14
   |
LL |         Some(a) if a.value == b {
   |                               - while parsing this struct
LL |             a.value = 1;
   |             -^ expected one of `,`, `:`, or `}`
   |             |
   |             while parsing this struct field
   |
help: try naming a field
   |
LL |             a: a.value = 1;
   |             ++
help: you might have meant to start a match arm after the match guard
   |
LL |         Some(a) if a.value == b => {
   |                                 ++
```

Fix #78585.
2023-10-03 21:21:02 +00:00
Esteban Küber
3848ffcee7 Tweak wording of missing angle backets in qualified path 2023-09-28 00:37:20 +00:00
yukang
f7cd892b5a add UI test for delimiter errors 2023-09-21 23:20:47 +08:00
León Orell Valerian Liehr
3ed77e98fa
Only suggest turbofish in patterns if we may recover 2023-09-12 16:38:59 +02:00
Gurinder Singh
6a286e775c Add explanatory note to 'expected item' error 2023-09-06 09:05:07 +05:30
Michael Goulet
dc946649f5 Clean up some bad ui testing annotations 2023-08-15 01:03:09 +00:00
darklyspaced
7c3a8aeea5
relocate tests to pass tidy 2023-08-07 22:40:09 +08:00
Matthias Krüger
51d1dacdc2
Rollup merge of #114300 - MU001999:fix/turbofish-pat, r=estebank
Suggests turbofish in patterns

Fixes #114112

r? ```@estebank```
2023-08-03 17:29:07 +02:00
Mu001999
049c728c60 Suggests turbofish in patterns 2023-08-01 23:30:40 +08:00
bohan
8e32dade71 parser: more friendly hints for handling async move in the 2015 edition 2023-07-31 11:04:28 +08:00
Matthias Krüger
9f2c21c11f
Rollup merge of #112518 - chenyukang:yukang-fix-112458, r=davidtwco
Detect actual span for getting unexpected token from parsing macros

Fixes #112458
2023-06-27 17:48:44 +02:00
yukang
0220c0b765 Detect actual span for getting unexpected token from parsing macros 2023-06-11 14:36:20 +08:00
yukang
e3071eaa60 reword the message to suggest surrounding with parentheses 2023-06-10 06:28:35 +08:00
yukang
3983881d4e take care module name for suggesting surround the struct literal in parentheses 2023-06-10 06:28:35 +08:00
Matthias Krüger
97fae38bf9
Rollup merge of #111181 - bvanjoi:fix-issue-111148, r=davidtwco
fix(parse): return unpected when current token is EOF

close https://github.com/rust-lang/rust/issues/111148

#111148 panic occurred because [FatalError.raise()](https://github.com/bvanjoi/rust/blob/master/compiler/rustc_parse/src/parser/mod.rs#LL540C3-L540C3) was encountered which caused by `Eof` and `Pound`(the last token) had same span, when parsing `#` in `fn a<<i<Y<w<>#`.

<img width="825" alt="image" src="https://user-images.githubusercontent.com/30187863/236612589-9e2c6a0b-18cd-408c-b636-c12a51cbcf1c.png">

There are a few ways to solve this problem:

- Change the action assign for [self.last_unexpected_token_span](https://github.com/rust-lang/rust/blob/master/compiler/rustc_parse/src/parser/diagnostics.rs#L592), for example, if current token is `Eof`, then return Error directly.
- Avoid triggering the `FatalError` when the current token is `Eof`.

I have chosen the second option because executing `expected_one_of_not_found` when the token is `Eof` but not in `ediable` seems reasonable.
2023-05-27 20:40:28 +02:00
yukang
83789b8b06 fmt 2023-05-13 19:40:17 +08:00
yukang
ce6cfc37d0 Fix ice caused by shorthand fields in NoFieldsForFnCall 2023-05-13 18:06:16 +08:00
bohan
272dc5a6d5 fix(parse): return unpected when current token is EOF 2023-05-13 00:33:27 +08:00
Michael Goulet
6e01e910cb Implement negative bounds 2023-05-02 22:36:24 +00:00
bors
98c33e47a4 Auto merge of #109128 - chenyukang:yukang/remove-type-ascription, r=estebank
Remove type ascription from parser and diagnostics

Mostly based on https://github.com/rust-lang/rust/pull/106826

Part of #101728

r? `@estebank`
2023-05-02 09:41:35 +00:00