Commit Graph

1698 Commits

Author SHA1 Message Date
Nicholas Nethercote
e7724a2e31 Add level arg to into_diagnostic.
And make all hand-written `IntoDiagnostic` impls generic, by using
`DiagnosticBuilder::new(dcx, level, ...)` instead of e.g.
`dcx.struct_err(...)`.

This means the `create_*` functions are the source of the error level.
This change will let us remove `struct_diagnostic`.

Note: `#[rustc_lint_diagnostics]` is added to `DiagnosticBuilder::new`,
it's necessary to pass diagnostics tests now that it's used in
`into_diagnostic` functions.
2023-12-19 09:19:25 +11:00
Nicholas Nethercote
cea683c08f Use .into_diagnostic() less.
This commit replaces this pattern:
```
err.into_diagnostic(dcx)
```
with this pattern:
```
dcx.create_err(err)
```
in a lot of places.

It's a little shorter, makes the error level explicit, avoids some
`IntoDiagnostic` imports, and is a necessary prerequisite for the next
commit which will add a `level` arg to `into_diagnostic`.

This requires adding `track_caller` on `create_err` to avoid mucking up
the output of `tests/ui/track-diagnostics/track4.rs`. It probably should
have been there already.
2023-12-18 20:46:13 +11:00
Nicholas Nethercote
f422dca3ae Rename many DiagCtxt arguments. 2023-12-18 16:06:22 +11:00
Nicholas Nethercote
73bac456d4 Rename Parser::span_diagnostic as Parser::dcx. 2023-12-18 16:06:21 +11:00
Nicholas Nethercote
9df1576e1d Rename ParseSess::span_diagnostic as ParseSess::dcx. 2023-12-18 16:06:21 +11:00
Nicholas Nethercote
cde19c016e Rename Handler as DiagCtxt. 2023-12-18 16:06:19 +11:00
bors
3ad8e2d129 Auto merge of #118897 - nnethercote:more-unescaping-cleanups, r=fee1-dead
More unescaping cleanups

More minor improvements I found while working on #118699.

r? `@fee1-dead`
2023-12-16 08:52:06 +00:00
Matthias Krüger
8479945c08 NFC don't convert types to identical types 2023-12-15 23:56:24 +01:00
Jubilee
9e872b7cd8
Rollup merge of #118933 - nnethercote:cleanup-errors-even-more, r=compiler-errors
Cleanup errors handlers even more

A sequel to #118587.

r? `@compiler-errors`
2023-12-14 16:07:48 -08:00
Nicholas Nethercote
9a78412511 Split Handler::emit_diagnostic in two.
Currently, `emit_diagnostic` takes `&mut self`.

This commit changes it so `emit_diagnostic` takes `self` and the new
`emit_diagnostic_without_consuming` function takes `&mut self`.

I find the distinction useful. The former case is much more common, and
avoids a bunch of `mut` and `&mut` occurrences. We can also restrict the
latter with `pub(crate)` which is nice.
2023-12-15 10:13:12 +11:00
Nicholas Nethercote
19d28a4f28 Change msg: impl Into<String> for bug diagnostics.
To `msg: impl Into<DiagnosticMessage>`, like all the other diagnostics.
For consistency.
2023-12-15 09:42:14 +11:00
Nicholas Nethercote
e3b7ecc1ef Remove one use of span_bug_no_panic.
It's unclear why this is used here. All entries in the third column of
`UNICODE_ARRAY` are covered by `ASCII_ARRAY`, so if the lookup fails
it's a genuine compiler bug. It was added way back in #29837, for no
clear reason.

This commit changes it to `span_bug`, which is more typical.
2023-12-14 15:53:55 +11:00
Nicholas Nethercote
7bdb227567 Avoid struct_diagnostic where possible.
It's necessary for `derive(Diagnostic)`, but is best avoided elsewhere
because there are clearer alternatives.

This required adding `Handler::struct_almost_fatal`.
2023-12-14 15:53:55 +11:00
Jubilee
f9078a40ee
Rollup merge of #118891 - compiler-errors:async-gen-blocks, r=eholk
Actually parse async gen blocks correctly

1. I got the control flow in `parse_expr_bottom` messed up, and obviously forgot a test for `async gen`, so we weren't actually ever parsing it correctly.
2. I forgot to gate the span for `async gen {}`, so even if we did parse it, we wouldn't have correctly denied it in `cfg(FALSE)`.

r? eholk
2023-12-12 18:48:55 -08:00
Nicholas Nethercote
423bf4233d Rename the span args to emit_unescape_error.
The `span` arg is described in a comment as "interior span of the
literal, without quotes", which is incorrect. It's actually the span of
the error part of the literal, corresponding to `range`.

This commit renames `span` and `span_without_quotes` to make things
clearer, and fixes the erroneous comment.
2023-12-13 10:05:57 +11:00
Michael Goulet
1d78ce681e Actually parse async gen blocks correctly 2023-12-12 20:13:37 +00:00
Matthias Krüger
d661974017
Rollup merge of #118868 - Nadrieril:correctly-gate-never_patterns-parsing, r=petrochenkov
Correctly gate the parsing of match arms without body

https://github.com/rust-lang/rust/pull/118527 accidentally allowed the following to parse on stable:
```rust
match Some(0) {
    None => { foo(); }
    #[cfg(FALSE)]
    Some(_)
}
```

This fixes that oversight. The way I choose which error to emit is the best I could think of, I'm open if you know a better way.

r? `@petrochenkov` since you're the one who noticed
2023-12-12 17:40:56 +01:00
Nadrieril
19e0c984d3 Don't gate the feature twice 2023-12-12 14:52:05 +01:00
Nadrieril
e274372689 Correctly gate the parsing of match arms without body 2023-12-12 14:42:04 +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
Nicholas Nethercote
4cfdbd328b Add spacing information to delimiters.
This is an extension of the previous commit. It means the output of
something like this:
```
stringify!(let a: Vec<u32> = vec![];)
```
goes from this:
```
let a: Vec<u32> = vec![] ;
```
With this PR, it now produces this string:
```
let a: Vec<u32> = vec![];
```
2023-12-11 09:36:40 +11:00
Nicholas Nethercote
925f7fad57 Improve print_tts by changing tokenstream::Spacing.
`tokenstream::Spacing` appears on all `TokenTree::Token` instances,
both punct and non-punct. Its current usage:
- `Joint` means "can join with the next token *and* that token is a
  punct".
- `Alone` means "cannot join with the next token *or* can join with the
  next token but that token is not a punct".

The fact that `Alone` is used for two different cases is awkward.
This commit augments `tokenstream::Spacing` with a new variant
`JointHidden`, resulting in:
- `Joint` means "can join with the next token *and* that token is a
  punct".
- `JointHidden` means "can join with the next token *and* that token is a
  not a punct".
- `Alone` means "cannot join with the next token".

This *drastically* improves the output of `print_tts`. For example,
this:
```
stringify!(let a: Vec<u32> = vec![];)
```
currently produces this string:
```
let a : Vec < u32 > = vec! [] ;
```
With this PR, it now produces this string:
```
let a: Vec<u32> = vec![] ;
```
(The space after the `]` is because `TokenTree::Delimited` currently
doesn't have spacing information. The subsequent commit fixes this.)

The new `print_tts` doesn't replicate original code perfectly. E.g.
multiple space characters will be condensed into a single space
character. But it's much improved.

`print_tts` still produces the old, uglier output for code produced by
proc macros. Because we have to translate the generated code from
`proc_macro::Spacing` to the more expressive `token::Spacing`, which
results in too much `proc_macro::Along` usage and no
`proc_macro::JointHidden` usage. So `space_between` still exists and
is used by `print_tts` in conjunction with the `Spacing` field.

This change will also help with the removal of `Token::Interpolated`.
Currently interpolated tokens are pretty-printed nicely via AST pretty
printing. `Token::Interpolated` removal will mean they get printed with
`print_tts`. Without this change, that would result in much uglier
output for code produced by decl macro expansions. With this change, AST
pretty printing and `print_tts` produce similar results.

The commit also tweaks the comments on `proc_macro::Spacing`. In
particular, it refers to "compound tokens" rather than "multi-char
operators" because lifetimes aren't operators.
2023-12-11 09:19:09 +11:00
surechen
40ae34194c remove redundant imports
detects redundant imports that can be eliminated.

for #117772 :

In order to facilitate review and modification, split the checking code and
removing redundant imports code into two PR.
2023-12-10 10:56:22 +08:00
bors
f967532a47 Auto merge of #118420 - compiler-errors:async-gen, r=eholk
Introduce support for `async gen` blocks

I'm delighted to demonstrate that `async gen` block are not very difficult to support. They're simply coroutines that yield `Poll<Option<T>>` and return `()`.

**This PR is WIP and in draft mode for now** -- I'm mostly putting it up to show folks that it's possible. This PR needs a lang-team experiment associated with it or possible an RFC, since I don't think it falls under the jurisdiction of the `gen` RFC that was recently authored by oli (https://github.com/rust-lang/rfcs/pull/3513, https://github.com/rust-lang/rust/issues/117078).

### Technical note on the pre-generator-transform yield type:

The reason that the underlying coroutines yield `Poll<Option<T>>` and not `Poll<T>` (which would make more sense, IMO, for the pre-transformed coroutine), is because the `TransformVisitor` that is used to turn coroutines into built-in state machine functions would have to destructure and reconstruct the latter into the former, which requires at least inserting a new basic block (for a `switchInt` terminator, to match on the `Poll` discriminant).

This does mean that the desugaring (at the `rustc_ast_lowering` level) of `async gen` blocks is a bit more involved. However, since we already need to intercept both `.await` and `yield` operators, I don't consider it much of a technical burden.

r? `@ghost`
2023-12-08 19:13:57 +00:00
Michael Goulet
a208bae00e Support async gen fn 2023-12-08 17:23:26 +00:00
Michael Goulet
2806c2df7b coro_kind -> coroutine_kind 2023-12-08 17:23:25 +00:00
Michael Goulet
96bb542a31 Implement async gen blocks 2023-12-08 17:23:25 +00: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
Matthias Krüger
71a8ca0522
Rollup merge of #116420 - bvanjoi:fix-116203, r=Nilstrieb
discard invalid spans in external blocks

Fixes #116203

This PR has discarded the invalid `const_span`, thereby making the format more neat.

r? ``@Nilstrieb``
2023-12-07 21:38:07 +01:00
bors
1dd4db5062 Auto merge of #118655 - compiler-errors:rollup-vrngyzn, r=compiler-errors
Rollup of 9 pull requests

Successful merges:

 - #117793 (Update variable name to fix `unused_variables` warning)
 - #118123 (Add support for making lib features internal)
 - #118268 (Pretty print `Fn<(..., ...)>` trait refs with parentheses (almost) always)
 - #118346 (Add `deeply_normalize_for_diagnostics`, use it in coherence)
 - #118350 (Simplify Default for tuples)
 - #118450 (Use OnceCell in cell module documentation)
 - #118585 (Fix parser ICE when recovering `dyn`/`impl` after `for<...>`)
 - #118587 (Cleanup error handlers some more)
 - #118642 (bootstrap(builder.rs): Don't explicitly warn against `semicolon_in_expressions_from_macros`)

r? `@ghost`
`@rustbot` modify labels: rollup
2023-12-06 04:20:51 +00:00
Michael Goulet
e8133700a2
Rollup merge of #118587 - nnethercote:cleanup-error-handlers-2, r=compiler-errors
Cleanup error handlers some more

A sequel to #118470.

r? ```@compiler-errors```
2023-12-05 14:52:44 -05:00
Michael Goulet
dbcde57171
Rollup merge of #118585 - sjwang05:issue-118564, r=compiler-errors
Fix parser ICE when recovering `dyn`/`impl` after `for<...>`

Fixes #118564
2023-12-05 14:52:43 -05:00
bors
56278a6e28 Auto merge of #118457 - eholk:genfn, r=compiler-errors
Add support for `gen fn`

This builds on #116447 to add support for `gen fn` functions. For the most part we follow the same approach as desugaring `async fn`, but replacing `Future` with `Iterator` and `async {}` with `gen {}` for the body.

The version implemented here uses the return type of a `gen fn` as the yield type. For example:

```rust
gen fn count_to_three() -> i32 {
    yield 1;
    yield 2;
    yield 3;
}
```

In the future, I think we should experiment with a syntax like `gen fn count_to_three() yield i32 { ... }`, but that can go in another PR.

cc `@oli-obk` `@compiler-errors`
2023-12-05 18:37:15 +00:00
Matthias Krüger
2d01eeeeac
Rollup merge of #117922 - estebank:unclosed-generics, r=b-naber
Tweak unclosed generics errors

Remove unnecessary span label for parse errors that already have a suggestion.

Provide structured suggestion to close generics in more cases.
2023-12-05 16:08:34 +01:00
Eric Holk
50ef8006eb
Address code review feedback 2023-12-04 14:33:46 -08:00
Eric Holk
f9d1f922dc
Option<CoroutineKind> 2023-12-04 13:03:37 -08:00
Eric Holk
48d5f1f0f2
Merge Async and Gen into CoroutineKind 2023-12-04 12:48:01 -08:00
Eric Holk
f29b36d03e
Make async gen fn an error 2023-12-04 11:23:07 -08:00
Eric Holk
7c43784cb0
gate gen fn behind gen_blocks 2023-12-04 11:23:06 -08:00
Eric Holk
c104f3b629
Lower return types for gen fn to impl Iterator 2023-12-04 11:23:05 -08:00
Eric Holk
bc0d10d4b0
Add genness to FnHeader 2023-12-04 11:22:49 -08:00
sjwang05
d627e2a4e8
Fix parser ICE when recovering dyn/impl after for<...> 2023-12-04 10:40:09 -08:00
Nicholas Nethercote
b7e18cabd2 De-genericize some IntoDiagnostic impls.
These impls are all needed for just a single `IntoDiagnostic` type, not
a family of them.

Note that `ErrorGuaranteed` is the default type parameter for
`IntoDiagnostic`.
2023-12-04 18:57:42 +11:00
Nadrieril
0bfebc6105 Detect attempts to expand a macro to a match arm again
Because a macro invocation can expand to a never pattern, we can't rule
out a `arm!(),` arm at parse time. Instead we detect that case at
expansion time, if the macro tries to output a pattern followed by `=>`.
2023-12-03 12:25:46 +01: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
bors
2da59b8676 Auto merge of #118470 - nnethercote:cleanup-error-handlers, r=compiler-errors
Cleanup error handlers

Mostly by making function naming more consistent. More to do after this, but this is enough for one PR.

r? compiler-errors
2023-12-02 02:48:34 +00:00
Nicholas Nethercote
31ac4efb31 Use Session::diagnostic in more places. 2023-12-02 09:01:35 +11:00
Nicholas Nethercote
5d1d384443 Rename HandlerInner::delay_span_bug as HandlerInner::span_delayed_bug.
Because the corresponding `Level` is `DelayedBug` and `span_delayed_bug`
follows the pattern used everywhere else: `span_err`, `span_warning`,
etc.
2023-12-02 09:01:19 +11:00
Esteban Küber
4e99db9e54 Tweak unclosed generics errors
Remove unnecessary span label for parse errors that already have a
suggestion.

Provide structured suggestion to close generics in more cases.
2023-12-01 20:01:39 +00:00
bors
63d16b5a98 Auto merge of #117472 - jmillikin:stable-c-str-literals, r=Nilstrieb
Stabilize C string literals

RFC: https://rust-lang.github.io/rfcs/3348-c-str-literal.html

Tracking issue: https://github.com/rust-lang/rust/issues/105723

Documentation PR (reference manual): https://github.com/rust-lang/reference/pull/1423

# Stabilization report

Stabilizes C string and raw C string literals (`c"..."` and `cr#"..."#`), which are expressions of type [`&CStr`](https://doc.rust-lang.org/stable/core/ffi/struct.CStr.html). Both new literals require Rust edition 2021 or later.

```rust
const HELLO: &core::ffi::CStr = c"Hello, world!";
```

C strings may contain any byte other than `NUL` (`b'\x00'`), and their in-memory representation is guaranteed to end with `NUL`.

## Implementation

Originally implemented by PR https://github.com/rust-lang/rust/pull/108801, which was reverted due to unintentional changes to lexer behavior in Rust editions < 2021.

The current implementation landed in PR https://github.com/rust-lang/rust/pull/113476, which restricts C string literals to Rust edition >= 2021.

## Resolutions to open questions from the RFC

* Adding C character literals (`c'.'`) of type `c_char` is not part of this feature.
  * Support for `c"..."` literals does not prevent `c'.'` literals from being added in the future.
* C string literals should not be blocked on making `&CStr` a thin pointer.
  * It's possible to declare constant expressions of type `&'static CStr` in stable Rust (as of v1.59), so C string literals are not adding additional coupling on the internal representation of `CStr`.
* The unstable `concat_bytes!` macro should not accept `c"..."` literals.
  * C strings have two equally valid `&[u8]` representations (with or without terminal `NUL`), so allowing them to be used in `concat_bytes!` would be ambiguous.
* Adding a type to represent C strings containing valid UTF-8 is not part of this feature.
  * Support for a hypothetical `&Utf8CStr` may be explored in the future, should such a type be added to Rust.
2023-12-01 13:33:55 +00:00
Esteban Küber
88453aaccf Avoid unnecessary pattern parse errors on ref box 2023-11-29 18:47:32 +00: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
1575e6e96e review comment: rework parse_for_head to reduce branching 2023-11-29 18:47:32 +00:00
Esteban Küber
0ff331bc78 Change how for (x in foo) {} is handled
Use the same approach used for match arm patterns.
2023-11-29 18:47:32 +00:00
Esteban Küber
c47318983b Account for (pat if expr) => {}
When encountering match arm (pat if expr) => {}, recover and suggest removing parentheses. Fix #100825.
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
075c599188 More accurate span for unnecessary parens suggestion 2023-11-29 18:47:31 +00:00
Esteban Küber
ed084a9343 When parsing patterns, bubble all errors except reserved idents that aren't likely to appear in for head or match arm 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
Matthias Krüger
aab61d0b9a
Rollup merge of #118191 - estebank:let-chain-typo, r=compiler-errors
Suggest `let` or `==` on typo'd let-chain

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-29 12:34:48 +01:00
Matthias Krüger
c03f8917ee
Rollup merge of #118157 - Nadrieril:never_pat-feature-gate, r=compiler-errors
Add `never_patterns` feature gate

This PR adds the feature gate and most basic parsing for the experimental `never_patterns` feature. See the tracking issue (https://github.com/rust-lang/rust/issues/118155) for details on the experiment.

`@scottmcm` has agreed to be my lang-team liaison for this experiment.
2023-11-29 12:34:47 +01:00
Matthias Krüger
20473eba0b
Rollup merge of #118394 - nnethercote:rm-hir-Ops, r=cjgillot
Remove HIR opkinds

`hir::BinOp`, `hir::BinOpKind`, and `hir::UnOp` are identical to `ast::BinOp`, `ast::BinOpKind`, and `ast::UnOp`, respectively. This seems silly, so this PR removes the HIR ones. (A re-export lets the AST ones be referred to using a `hir::` qualifier, which avoids renaming churn.)

r? `@cjgillot`
2023-11-29 04:23:23 +01:00
Nadrieril
a3838c8550 Add never_patterns feature gate 2023-11-29 03:58:29 +01:00
Esteban Küber
55e4e3e393 Suggest let or == on typo'd let-chain
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-28 18:07:52 +00:00
Michael Goulet
203aaf62a9
Rollup merge of #111133 - hkmatsumoto:handle-python-slicing, r=TaKO8Ki
Detect Python-like slicing and suggest how to fix

Fix #108215
2023-11-27 19:06:45 -05:00
Nicholas Nethercote
705b484922 Rename BinOpKind::lazy as BinOpKind::is_lazy.
To match `BinOpKind::is_comparison` and `hir::BinOpKind::is_lazy`.
2023-11-28 09:45:40 +11:00
Nicholas Nethercote
0efd2a9d8f Rework ast::BinOpKind::to_string and ast::UnOp::to_string.
- Rename them both `as_str`, which is the typical name for a function
  that returns a `&str`. (`to_string` is appropriate for functions
  returning `String` or maybe `Cow<'a, str>`.)
- Change `UnOp::as_str` from an associated function (weird!) to a
  method.
- Avoid needless `self` dereferences.
2023-11-28 09:42:07 +11:00
Hirochika Matsumoto
acec70de9b Change help message to make some sense in broader context 2023-11-27 22:18:03 +09:00
Hirochika Matsumoto
730d299354 Address review feedbacks
Also addressed merge conflicts upon rebasing.
2023-11-27 22:06:42 +09:00
Hirochika Matsumoto
61c3e4d56e Make tidy test happy 2023-11-27 21:48:10 +09:00
Hirochika Matsumoto
e65c060d78 Detect Python-like slicing and suggest how to fix
Fix #108215
2023-11-27 21:48:10 +09:00
Hirochika Matsumoto
f4c2bdeec9 Suggest swapping the order of ref and box 2023-11-27 21:38:19 +09:00
Nicholas Nethercote
57cd5e6551 Use rustc_fluent_macro::fluent_messages! directly.
Currently we always do this:
```
use rustc_fluent_macro::fluent_messages;
...
fluent_messages! { "./example.ftl" }
```
But there is no need, we can just do this everywhere:
```
rustc_fluent_macro::fluent_messages! { "./example.ftl" }
```
which is shorter.
2023-11-26 08:38:40 +11:00
Nicholas Nethercote
a733082be9 Avoid need for {D,Subd}iagnosticMessage imports.
The `fluent_messages!` macro produces uses of
`crate::{D,Subd}iagnosticMessage`, which means that every crate using
the macro must have this import:
```
use rustc_errors::{DiagnosticMessage, SubdiagnosticMessage};
```

This commit changes the macro to instead use
`rustc_errors::{D,Subd}iagnosticMessage`, which avoids the need for the
imports.
2023-11-26 08:38:00 +11:00
Deadbeef
16040a1628 Add Span to TraitBoundModifier 2023-11-24 14:32:05 +00:00
Nilstrieb
21a870515b Fix clippy::needless_borrow in the compiler
`x clippy compiler -Aclippy::all -Wclippy::needless_borrow --fix`.

Then I had to remove a few unnecessary parens and muts that were exposed
now.
2023-11-21 20:13:40 +01:00
Michael Goulet
e6a3ca0c65
Rollup merge of #117988 - estebank:issue-106020, r=cjgillot
Handle attempts to have multiple `cfg`d tail expressions

When encountering code that seems like it might be trying to have multiple tail expressions depending on `cfg` information, suggest alternatives that will success to parse.

```rust
fn foo() -> String {
    #[cfg(feature = "validation")]
    [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>()
    #[cfg(not(feature = "validation"))]
    String::new()
}
```

```
error: expected `;`, found `#`
  --> $DIR/multiple-tail-expr-behind-cfg.rs:5:64
   |
LL |     #[cfg(feature = "validation")]
   |     ------------------------------ only `;` terminated statements or tail expressions are allowed after this attribute
LL |     [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>()
   |                                                                ^ expected `;` here
LL |     #[cfg(not(feature = "validation"))]
   |     - unexpected token
   |
help: add `;` here
   |
LL |     [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>();
   |                                                                +
help: alternatively, consider surrounding the expression with a block
   |
LL |     { [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>() }
   |     +                                                             +
help: it seems like you are trying to provide different expressions depending on `cfg`, consider using `if cfg!(..)`
   |
LL ~     if cfg!(feature = "validation") {
LL ~         [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>()
LL ~     } else if cfg!(not(feature = "validation")) {
LL ~         String::new()
LL +     }
   |
```

Fix #106020.

r? `@oli-obk`
2023-11-19 19:14:34 -08:00
Michael Goulet
a7f805d277
Rollup merge of #117891 - compiler-errors:recover-for-dyn, r=davidtwco
Recover `dyn` and `impl` after `for<...>`

Recover `dyn` and `impl` after `for<...>` in types. Reuses the logic for parsing bare trait objects, so it doesn't fix cases like `for<'a> dyn Trait + dyn Trait` or anything, but that seems somewhat of a different issue.

Parsing recovery logic is a bit involved, but I couldn't find a way to simplify it.

Fixes #117882
2023-11-19 19:14:33 -08:00
Esteban Küber
f1ae02f4bd Don't sort span_suggestions, leave that to caller 2023-11-19 17:50:45 +00:00
bors
2831701757 Auto merge of #114292 - estebank:issue-71039, r=b-naber
More detail when expecting expression but encountering bad macro argument

On nested macro invocations where the same macro fragment changes fragment type from one to the next, point at the chain of invocations and at the macro fragment definition place, explaining that the change has occurred.

Fix #71039.

```
error: expected expression, found pattern `1 + 1`
  --> $DIR/trace_faulty_macros.rs:49:37
   |
LL |     (let $p:pat = $e:expr) => {test!(($p,$e))};
   |                   -------                -- this is interpreted as expression, but it is expected to be pattern
   |                   |
   |                   this macro fragment matcher is expression
...
LL |     (($p:pat, $e:pat)) => {let $p = $e;};
   |               ------                ^^ expected expression
   |               |
   |               this macro fragment matcher is pattern
...
LL |     test!(let x = 1+1);
   |     ------------------
   |     |             |
   |     |             this is expected to be expression
   |     in this macro invocation
   |
   = note: when forwarding a matched fragment to another macro-by-example, matchers in the second macro will see an opaque AST of the fragment type, not the underlying tokens
   = note: this error originates in the macro `test` (in Nightly builds, run with -Z macro-backtrace for more info)
```
2023-11-17 20:57:12 +00: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
Matthias Krüger
92aba63d6b
Rollup merge of #117892 - estebank:fat-arrow-typo, r=compiler-errors
Detect more `=>` typos

Handle and recover `match expr { pat >= { arm } }`.
2023-11-17 00:41:22 +01:00
Esteban Küber
099eb40932 Fix code indentation 2023-11-16 21:54:04 +00:00
Esteban Küber
a16722d221 Handle attempts to have multiple cfgd tail expressions
When encountering code that seems like it might be trying to have
multiple tail expressions depending on `cfg` information, suggest
alternatives that will success to parse.

```rust
fn foo() -> String {
    #[cfg(feature = "validation")]
    [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>()
    #[cfg(not(feature = "validation"))]
    String::new()
}
```

```
error: expected `;`, found `#`
  --> $DIR/multiple-tail-expr-behind-cfg.rs:5:64
   |
LL |     #[cfg(feature = "validation")]
   |     ------------------------------ only `;` terminated statements or tail expressions are allowed after this attribute
LL |     [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>()
   |                                                                ^ expected `;` here
LL |     #[cfg(not(feature = "validation"))]
   |     - unexpected token
   |
help: add `;` here
   |
LL |     [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>();
   |                                                                +
help: alternatively, consider surrounding the expression with a block
   |
LL |     { [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>() }
   |     +                                                             +
help: it seems like you are trying to provide different expressions depending on `cfg`, consider using `if cfg!(..)`
   |
LL ~     if cfg!(feature = "validation") {
LL ~         [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>()
LL ~     } else if cfg!(not(feature = "validation")) {
LL ~         String::new()
LL +     }
   |
```

Fix #106020.
2023-11-16 21:21:26 +00:00
Esteban Küber
1c6bd0b12b Smaller span for unnessary mut suggestion 2023-11-16 16:58:41 +00:00
Esteban Küber
4e418805da More detail when expecting expression but encountering bad macro argument
Partially address #71039.
2023-11-16 16:19:04 +00:00
Mark Rousskov
917f6540ed Re-format code with new rustfmt 2023-11-15 21:45:48 -05:00
bohan
4138702621 discard invalid spans in external blocks 2023-11-15 15:28:38 +08:00
cui fliter
a44a4edc0e Fix some typos
Signed-off-by: cui fliter <imcusg@gmail.com>
2023-11-14 23:06:50 +08:00
Esteban Küber
f830fe313b Detect more => typos
Handle and recover `match expr { pat >= { arm } }`.
2023-11-14 00:46:37 +00:00
Michael Goulet
a8a2ee4e8f Recover dyn and impl after for<...> 2023-11-14 00:15:10 +00:00
bors
ea1e5cc91f Auto merge of #117770 - sjwang05:issue-117766, r=estebank,TaKO8Ki
Catch stray `{` in let-chains

Fixes #117766
2023-11-13 01:57:59 +00:00
sjwang05
274824b917
Fix is_keyword_ahead visibility
Co-authored-by: Takayuki Maeda <takoyaki0316@gmail.com>
2023-11-12 14:46:01 -08:00
sjwang05
f88cf0206f
Move unclosed delim errors to separate function 2023-11-11 13:39:08 -08:00
sjwang05
a49368f00b
Correctly handle while-let-chains 2023-11-10 12:13:53 -08:00
sjwang05
9455259450
Catch an edge case 2023-11-09 20:07:17 -08:00
sjwang05
0094238157
Catch stray { in let-chains 2023-11-09 18:47:49 -08:00
sjwang05
5693a34db2
Suggest fix for ; within let-chains 2023-11-09 00:31:42 -08: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
Dinu Blanovschi
a6b41aa6ba fmt 2023-11-04 20:04:02 +01:00
Dinu Blanovschi
8de489918b feat(hir): Store the Span of the move keyword 2023-11-04 19:39:32 +01:00
bors
9c20ddd956 Auto merge of #117507 - nnethercote:rustc_span, r=Nilstrieb
`rustc_span` cleanups

Just some things I found while looking over this crate.

r? `@oli-obk`
2023-11-03 14:57:40 +00:00
Nicholas Nethercote
f405ce86c2 Minimize pub usage in source_map.rs.
Most notably, this commit changes the `pub use crate::*;` in that file
to `use crate::*;`. This requires a lot of `use` items in other crates
to be adjusted, because everything defined within `rustc_span::*` was
also available via `rustc_span::source_map::*`, which is bizarre.

The commit also removes `SourceMap::span_to_relative_line_string`, which
is unused.
2023-11-02 19:35:00 +11:00
Matthias Krüger
2b2360abb1
Rollup merge of #117298 - clubby789:fn-missing-params, r=petrochenkov
Recover from missing param list in function definitions

Addresses the other issue mentioned in #108109
2023-11-01 21:40:05 +01:00
bors
b0a07595b5 Auto merge of #117289 - estebank:issue-72298, r=cjgillot
Account for `ref` and `mut` in the wrong place for pattern ident renaming

If the user writes `S { ref field: name }` instead of `S { field: ref name }`, we suggest the correct code.

Fix #72298.
2023-11-01 18:39:01 +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
John Millikin
0f41bc21b9 Stabilize C string literals 2023-11-01 09:16:34 +09:00
Matthias Krüger
7035c3d718
Rollup merge of #116712 - estebank:issue-116252, r=petrochenkov
When encountering unclosed delimiters during lexing, check for diff markers

Fix #116252.
2023-10-31 12:55:09 +01:00
bors
31bc7e2c47 Auto merge of #117415 - matthiaskrgr:rollup-jr2p1t2, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #116862 (Detect when trait is implemented for type and suggest importing it)
 - #117389 (Some diagnostics improvements of `gen` blocks)
 - #117396 (Don't treat closures/coroutine types as part of the public API)
 - #117398 (Correctly handle nested or-patterns in exhaustiveness)
 - #117403 (Poison check_well_formed if method receivers are invalid to prevent typeck from running on it)
 - #117411 (Improve some diagnostics around `?Trait` bounds)
 - #117414 (Don't normalize to an un-revealed opaque when we hit the recursion limit)

r? `@ghost`
`@rustbot` modify labels: rollup
2023-10-30 20:50:14 +00:00
Oli Scherer
745c600617 Talk about gen fn in diagnostics about gen fn 2023-10-30 10:13:12 +00:00
Esteban Küber
50ca5ef07f When encountering unclosed delimiters during parsing, check for diff markers
Fix #116252.
2023-10-30 00:56:46 +00:00
Esteban Küber
b589f47441 Account for ref and mut in the wrong place for pattern ident renaming
If the user writes `S { ref field: name }` instead of
`S { field: ref name }`, we suggest the correct code.

Fix #72298.
2023-10-30 00:15:49 +00:00
Nicholas Nethercote
8ff624a9f2 Clean up rustc_*/Cargo.toml.
- Sort dependencies and features sections.
- Add `tidy` markers to the sorted sections so they stay sorted.
- Remove empty `[lib`] sections.
- Remove "See more keys..." comments.

Excluded files:
- rustc_codegen_{cranelift,gcc}, because they're external.
- rustc_lexer, because it has external use.
- stable_mir, because it has external use.
2023-10-30 08:46:02 +11:00
bors
88ae8c9385 Auto merge of #116889 - MU001999:master, r=petrochenkov
Eat close paren if capture_cfg to avoid unbalanced parens

Fixes #116781
2023-10-29 16:46:47 +00:00
bors
2cad938a81 Auto merge of #116447 - oli-obk:gen_fn, r=compiler-errors
Implement `gen` blocks in the 2024 edition

Coroutines tracking issue https://github.com/rust-lang/rust/issues/43122
`gen` block tracking issue https://github.com/rust-lang/rust/issues/117078

This PR implements `gen` blocks that implement `Iterator`. Most of the logic with `async` blocks is shared, and thus I renamed various types that were referring to `async` specifically.

An example usage of `gen` blocks is

```rust
fn foo() -> impl Iterator<Item = i32> {
    gen {
        yield 42;
        for i in 5..18 {
            if i.is_even() { continue }
            yield i * 2;
        }
    }
}
```

The limitations (to be resolved) of the implementation are listed in the tracking issue
2023-10-29 00:03:52 +00:00
Mu001999
fe00cfef57 restore snapshot when parse_param_general 2023-10-28 08:53:51 +08:00
clubby789
be0b42fabe Recover from incorrectly ordered/duplicated function keywords 2023-10-27 18:29:43 +00:00
Matthias Krüger
b2295375f8
Rollup merge of #117212 - clubby789:fix-ternary-recover, r=compiler-errors
Properly restore snapshot when failing to recover parsing ternary

If the recovery parsed an expression, then failed to eat a `:`, it would return `false` without restoring the snapshot. Fix this by always restoring the snapshot when returning `false`.

Draft for now because I'd like to try and improve this recovery further.

Fixes #117208
2023-10-27 19:46:07 +02:00
Oli Scherer
4ac25faf9f Handle move generators 2023-10-27 13:05:48 +00:00
Oli Scherer
638d2d6fc1 Feature gate gen blocks, even in 2024 edition 2023-10-27 13:05:48 +00:00
Oli Scherer
621494382d Add gen blocks to ast and do some broken ast lowering 2023-10-27 13:05:48 +00:00
clubby789
e81a5c65d9 Recover ternary expression as error 2023-10-26 23:04:20 +00:00
clubby789
041f0313cf Properly restore snapshot when failing to recover parsing ternary 2023-10-26 11:11:36 +00:00
Oli Scherer
a61cf673cd Reserve gen keyword for gen {} blocks and gen fn in 2024 edition 2023-10-26 06:49:17 +00:00
Esteban Küber
2dec1bc685 Avoid unbounded O(n^2) when parsing nested type args
When encountering code like `f::<f::<f::<f::<f::<f::<f::<f::<...` with
unmatched closing angle brackets, add a linear check that avoids the
exponential behavior of the parse recovery mechanism.

Fix #117080.
2023-10-25 19:07:34 +00:00
Oli Scherer
e96ce20b34 s/generator/coroutine/ 2023-10-20 21:14:01 +00:00
Esteban Küber
20de5c762d Move where doc comment meant as comment check
The new place makes more sense and covers more cases beyond individual
statements.

```
error: expected one of `.`, `;`, `?`, `else`, or an operator, found doc comment `//!foo
  --> $DIR/doc-comment-in-stmt.rs:25:22
   |
LL |     let y = x.max(1) //!foo
   |                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected one of `.`, `;`, `?`, `else`, or an operator
   |
help: add a space before `!` to write a regular comment
   |
LL |     let y = x.max(1) // !foo
   |                        +
```

Fix #65329.
2023-10-20 02:54:45 +00:00
bors
a48396984a Auto merge of #116688 - compiler-errors:rustfmt-up, r=WaffleLapkin,Nilstrieb
Format all the let-chains in compiler crates

Since rust-lang/rustfmt#5910 has landed, soon we will have support for formatting let-chains (as soon as rustfmt syncs and beta gets bumped).

This PR applies the changes [from master rustfmt to rust-lang/rust eagerly](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/out.20formatting.20of.20prs/near/374997516), so that the next beta bump does not have to deal with a 200+ file diff and can remain concerned with other things like `cfg(bootstrap)` -- #113637 was a pain to land, for example, because of let-else.

I will also add this commit to the ignore list after it has landed.

The commands that were run -- I'm not great at bash-foo, but this applies rustfmt to every compiler crate, and then reverts the two crates that should probably be formatted out-of-tree.
```
~/rustfmt $ ls -1d ~/rust/compiler/* | xargs -I@ cargo run --bin rustfmt -- `@/src/lib.rs` --config-path ~/rust --edition=2021 # format all of the compiler crates
~/rust $ git checkout HEAD -- compiler/rustc_codegen_{gcc,cranelift} # revert changes to cg-gcc and cg-clif
```

cc `@rust-lang/rustfmt`
r? `@WaffleLapkin` or `@Nilstrieb` who said they may be able to review this purely mechanical PR :>

cc `@Mark-Simulacrum` and `@petrochenkov,` who had some thoughts on the order of operations with big formatting changes in https://github.com/rust-lang/rust/pull/95262#issue-1178993801. I think the situation has changed since then, given that let-chains support exists on master rustfmt now, and I'm fairly confident that this formatting PR should land even if *bootstrap* rustfmt doesn't yet format let-chains in order to lessen the burden of the next beta bump.
2023-10-15 13:23:55 +00:00
bors
09eff44889 Auto merge of #116645 - estebank:issue-116608, r=oli-obk
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-13 19:26:27 +00:00
Michael Goulet
b2d2184ede Format all the let chains in compiler 2023-10-13 08:59:36 +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
Nicholas Nethercote
bb9c2f50c3 Reorder an expression to improve readability. 2023-10-12 08:46:15 +11:00
Nicholas Nethercote
becf4942a2 Rename Token::is_op as Token::is_punct.
For consistency with `proc_macro::Punct`.
2023-10-12 08:46:15 +11: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
Michael Goulet
137b6d0b01 Point to where missing return type should go 2023-10-04 21:09:54 +00:00
Matthias Krüger
4ed2291624
Rollup merge of #116393 - compiler-errors:auto-bad, r=WaffleLapkin
Emit feature gate *warning* for `auto` traits pre-expansion

Auto traits were introduced before we were more careful about not stabilizing new syntax pre-expansion.

This is a more conservative step in the general direction we want to go in https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Removal.20of.20.60auto.20trait.60.20syntax.

Fixes #116121
2023-10-04 05:02:07 +02:00
Esteban Küber
8fd345dd4b review comments 2023-10-04 01:35:07 +00:00
Esteban Küber
18ec4e9bcd Move some tests around 2023-10-03 21:31:27 +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
Michael Goulet
7815641be0 Gate against auto traits pre-expansion 2023-10-03 19:12:00 +00:00
Matthias Krüger
144862ede8
Rollup merge of #115863 - chenyukang:yukang-add-message-tidy-check, r=davidtwco
Add check_unused_messages in tidy

From https://github.com/rust-lang/rust/pull/115728#issuecomment-1715490553
The check is not 100% accurate, I guess it's enough for now.
2023-10-03 12:24:11 +02:00
Esteban Küber
3848ffcee7 Tweak wording of missing angle backets in qualified path 2023-09-28 00:37:20 +00:00
yukang
42a033affa Cleanup unused messages in ftl files 2023-09-20 19:09:01 +08:00
bors
dac91a82e1 Auto merge of #115677 - matthewjasper:let-expr-recovery, r=b-naber
Improve invalid let expression handling

- Move all of the checks for valid let expression positions to parsing.
- Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location.
- Suppress some later errors and MIR construction for invalid let expressions.
- Fix a (drop) scope issue that was also responsible for #104172.

Fixes #104172
Fixes #104868
2023-09-14 19:56:55 +00:00
Matthew Jasper
e324a59eb6 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
León Orell Valerian Liehr
3ed77e98fa
Only suggest turbofish in patterns if we may recover 2023-09-12 16:38:59 +02:00
Matthew Jasper
b011a0a13b Reduce double errors for invalid let expressions
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-11 16:17:06 +00:00
Matthew Jasper
333388fd3c 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-11 15:51:18 +00:00
Matthias Krüger
da44234b64
Rollup merge of #115596 - nnethercote:two-small-changes, r=lqd
A small change

A small change I made while poking around the code.

r? `@lqd`
2023-09-06 19:31:50 +02:00
Matthias Krüger
4a31cc859b
Rollup merge of #115473 - gurry:113110-expected-item, r=compiler-errors
Add explanatory note to 'expected item' error

Fixes #113110

It changes the diagnostic from this:

```
error: expected item, found `5`
 --> ../test.rs:1:1
  |
1 | 5
  | ^ expected item
 ```
to this:
```
error: expected item, found `5`
 --> ../test.rs:1:1
  |
1 | 5
  | ^ expected item
  |
  = note: items are things that can appear at the root of a module
  = note: for a full list see https://doc.rust-lang.org/reference/items.html
```
2023-09-06 19:31:48 +02:00
Nicholas Nethercote
42dbc72d7b Adjust to_attr_token_stream.
It uses `once` chained with `(0..self.num_calls).map(...)` followed by
`.take(self.num_calls`. I found this hard to read. It's simpler to just
use `repeat_with`.
2023-09-06 17:12:07 +10:00
Gurinder Singh
6a286e775c Add explanatory note to 'expected item' error 2023-09-06 09:05:07 +05:30
bors
25283f4e13 Auto merge of #115371 - matthewjasper:if-let-guard-parsing, r=cjgillot
Make if let guard parsing consistent with normal guards

- Add tests that struct expressions are not allowed in `if let` and `while let` (no change, consistent with `if` and `while`)
- Allow struct expressions in `if let` guards (consistent with `if` guards).

r? `@cjgillot`

Closes #93817
cc #51114
2023-09-06 00:46:21 +00:00
Camille GILLOT
258ace613d Use relative positions inside a SourceFile. 2023-09-03 12:56:10 +00:00
Matthias Krüger
58c690729c
Rollup merge of #115347 - y21:generic-bound-impl-trait-ty, r=compiler-errors
suggest removing `impl` in generic trait bound position

rustc already does this recovery in type param position (`<T: impl Trait>` -> `<T: Trait>`).
This PR also adds that suggestion in trait bound position (e.g. `where T: impl Trait` or `trait Trait { type Assoc: impl Trait; }`)
2023-08-30 07:18:12 +02:00
Matthias Krüger
639116505a
Rollup merge of #114704 - bvanjoi:fix-114636, r=compiler-errors
parser: not insert dummy field in struct

Fixes #114636

This PR eliminates the dummy field, initially introduced in #113999, thereby enabling unrestricted use of `ident.unwrap()`. A side effect of this action is that we can only report the error of the first macro invocation field within the struct node.

An alternative solution might be giving a virtual name to the macro, but it appears more complex.(https://github.com/rust-lang/rust/issues/114636#issuecomment-1670228715). Furthermore, if you think https://github.com/rust-lang/rust/issues/114636#issuecomment-1670228715 is a better solution, feel free to close this PR.
2023-08-30 07:18:10 +02:00
y21
507f10baee suggest removing impl in generic trait bound position 2023-08-29 20:27:38 +02:00
Matthew Jasper
89235fd837 Allow stuct literals in if let guards
This is consistent with normal match guards.
2023-08-28 10:31:45 +01:00
bors
18be2728bd Auto merge of #115131 - frank-king:feature/unnamed-fields-lite, r=petrochenkov
Parse unnamed fields and anonymous structs or unions (no-recovery)

It is part of #114782 which implements #49804. Only parse anonymous structs or unions in struct field definition positions.

r? `@petrochenkov`
2023-08-24 12:52:35 +00:00
Frank King
868706d9b5 Parse unnamed fields and anonymous structs or unions
Anonymous structs or unions are only allowed in struct field
definitions.

Co-authored-by: carbotaniuman <41451839+carbotaniuman@users.noreply.github.com>
2023-08-24 11:17:54 +08:00
Mark Rousskov
0a916062aa Bump cfg(bootstrap) 2023-08-23 20:05:14 -04:00
bohan
3ed435f8cb discard dummy field for macro invocation when parse struct 2023-08-21 21:05:01 +08:00
John Kåre Alsaker
1e87ef66f4 Fix a stack overflow with long else if chains 2023-08-19 13:11:16 +02:00
bors
ee5cb9e3a6 Auto merge of #114915 - nnethercote:Nonterminal-cleanups, r=petrochenkov
`Nonterminal`-related cleanups

In #114647 I am trying to remove `Nonterminal`. It has a number of preliminary cleanups that are worth merging even if #114647 doesn't merge, so let's do them in this PR.

r? `@petrochenkov`
2023-08-18 16:07:40 +00:00
Nicholas Nethercote
9e22351c74 Rename NtOrTt as ParseNtResult.
It's more descriptive, and future-proofs it if/when additional variants
get added.
2023-08-18 16:50:41 +10:00
Nicholas Nethercote
9167eea553 Use interpolated_or_expr_span in one suitable place. 2023-08-18 16:50:41 +10:00
Nicholas Nethercote
dee6c9241f Refactor interpolated_or_expr_span.
It's much more complicated than it needs to be, and it doesn't modify
the expression. We can do the `Result` handling outside of it, and
change it to just return a span.

Also fix an errant comma that makes the comment hard to read.
2023-08-18 16:50:41 +10:00
Josh Stone
7ea4de9632
Rollup merge of #114913 - beetrees:escape-double-quote, r=davidtwco
Fix suggestion for attempting to define a string with single quotes

Currently attempting to compile `fn main() { let _ = '\\"'; }` will result in the following error message:
```
error: character literal may only contain one codepoint
 --> src/main.rs:1:21
  |
1 | fn main() { let _ = '\\"'; }
  |                     ^^^^^
  |
help: if you meant to write a `str` literal, use double quotes
  |
1 | fn main() { let _ = "\\""; }
  |                     ~~~~~
```
The suggestion is invalid as it fails to escape the `"`. This PR fixes the suggestion so that it now reads:
```
help: if you meant to write a `str` literal, use double quotes
  |
1 | fn main() { let _ = "\\\""; }
  |                     ~~~~~~
```
The relevant test is also updated to ensure that this does not regress in future.
2023-08-17 15:40:09 -07:00
Nicholas Nethercote
e46caaf84b Simplify a match.
`may_be_ident` is true for `NtPath` and `NtMeta`, so we don't need to
check for them separately.
2023-08-17 09:06:03 +10:00
Nicholas Nethercote
9a3c907bdb Make some matches exhaustive in nonterminal.rs.
For ones matching more than one or two variants, this is easier to think
about.
2023-08-17 09:05:37 +10:00
Nicholas Nethercote
f8a21a5df0 Use Nonterminal::* in nonterminal.rs.
It makes the code more readable.
2023-08-17 09:05:07 +10:00
Nicholas Nethercote
acd3a5e35f Remove unnecessary braces on PatWithOr patterns. 2023-08-17 09:04:54 +10:00
Nicholas Nethercote
e8f733370f Add some useful comments to Parser::look_ahead. 2023-08-17 09:03:56 +10:00
Nicholas Nethercote
04cf6b4ac5 Rename parse_no_question_mark_recover.
Adding a `ty_` makes its purpose much clearer, and consistent with other
`parse_ty_*` functions.
2023-08-17 09:01:12 +10:00
Nicholas Nethercote
434bfc3162 Remove outdated comment.
All nonterminals collect and store tokens now. (Unless they are very
simple, e.g. single-token, and can precisely recover them without
collecting.)
2023-08-17 08:26:56 +10:00
beetrees
072d8c8bbc
Fix suggestion for attempting to define a string with single quotes 2023-08-16 21:51:57 +01:00
yukang
ddcd7cac41 Fix bad suggestion when wrong parentheses around a dyn trait 2023-08-16 00:26:10 +08:00
bjorn3
ef2da4a49b Remove reached_eof from ParseSess
It was only ever set in a function which isn't called anywhere.
2023-08-13 13:33:37 +00:00
darklyspaced
89284af8fe
inlined kind 2023-08-08 10:59:15 +08:00
darklyspaced
13ac0234c6
always return ExprKind::Err 2023-08-07 22:32:28 +08:00
Matthias Krüger
99e4127d85
Rollup merge of #114434 - Nilstrieb:indexing-spans, r=est31
Improve spans for indexing expressions

fixes #114388

Indexing is similar to method calls in having an arbitrary left-hand-side and then something on the right, which is the main part of the expression. Method calls already have a span for that right part, but indexing does not. This means that long method chains that use indexing have really bad spans, especially when the indexing panics and that span in coverted into a panic location.

This does the same thing as method calls for the AST and HIR, storing an extra span which is then put into the `fn_span` field in THIR.

r? compiler-errors
2023-08-04 21:31:57 +02:00
Nilstrieb
5706be1854 Improve spans for indexing expressions
Indexing is similar to method calls in having an arbitrary
left-hand-side and then something on the right, which is the main part
of the expression. Method calls already have a span for that right part,
but indexing does not. This means that long method chains that use
indexing have really bad spans, especially when the indexing panics and
that span in coverted into a panic location.

This does the same thing as method calls for the AST and HIR, storing an
extra span which is then put into the `fn_span` field in THIR.
2023-08-04 13:17:39 +02:00
Matthias Krüger
1f076fe1d8
Rollup merge of #113999 - Centri3:macro-arm-expand, r=wesleywiser
Specify macro is invalid in certain contexts

Adds a note when a macro is used where it really shouldn't be.

Closes #113766
2023-08-04 07:25:45 +02:00
bors
1fe384649a Auto merge of #108955 - Nilstrieb:dont-use-me-pls, r=oli-obk
Add `internal_features` lint

Implements https://github.com/rust-lang/compiler-team/issues/596

Also requires some more test blessing for codegen tests etc

`@jyn514` had the idea of just `allow`ing the lint by default in the test suite. I'm not sure whether this is a good idea, but it's definitely one worth considering. Additional input encouraged.
2023-08-03 22:58:02 +00: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
Matthias Krüger
649d0a9525
Rollup merge of #114237 - bvanjoi:fix-114219, r=cjgillot
parser: more friendly hints for handling `async move` in the 2015 edition

Fixes #114219

An error is emitted when encountering an async move block in the 2015 edition.

Another appropriate location to raise an error is after executing [let path = this.parse_path(PathStyle::Expr)?](https://github.com/rust-lang/rust/blob/master/compiler/rustc_parse/src/parser/stmt.rs#L152), but it seems somewhat premature to invoke `create_err` at that stage.
2023-08-03 17:29:07 +02:00
Nilstrieb
5830ca216d Add internal_features lint
It lints against features that are inteded to be internal to the
compiler and standard library. Implements MCP #596.

We allow `internal_features` in the standard library and compiler as those
use many features and this _is_ the standard library from the "internal to the compiler and
standard library" after all.

Marking some features as internal wasn't exactly the most scientific approach, I just marked some
mostly obvious features. While there is a categorization in the macro,
it's not very well upheld (should probably be fixed in another PR).

We always pass `-Ainternal_features` in the testsuite
About 400 UI tests and several other tests use internal features.
Instead of throwing the attribute on each one, just always allow them.
There's nothing wrong with testing internal features^^
2023-08-03 14:50:50 +02:00
r0cky
dce7e87b16 Reduce arbitrary self type suggestions 2023-08-03 10:34:57 +00:00
r0cky
8c8af6cf99 Avoid too many expected symbols and reduce Nones 2023-08-03 08:56:31 +00:00
r0cky
41e85c3d23 Apply suggestions 2023-08-03 05:18:19 +00:00
Catherine Flores
bbd69e4a4c Add test for enum with fields 2023-08-02 23:59:30 +00:00
Nicholas Nethercote
d75ee2a6bc Remove MacDelimiter.
It's the same as `Delimiter`, minus the `Invisible` variant. I'm
generally in favour of using types to make impossible states
unrepresentable, but this one feels very low-value, and the conversions
between the two types are annoying and confusing.

Look at the change in `src/tools/rustfmt/src/expr.rs` for an example:
the old code converted from `MacDelimiter` to `Delimiter` and back
again, for no good reason. This suggests the author was confused about
the types.
2023-08-03 09:03:30 +10:00
Mu001999
89b2fe7750 Keep the suggestion for wrong arbitrary self types 2023-08-03 00:00:56 +08:00
Nicholas Nethercote
ac64a53e17 Avoid an unnecessary local variable. 2023-08-02 10:29:13 +10:00
Nicholas Nethercote
6fc2c481e5 Move TokenCursor::break_last_token into Parser.
Similar to the last commit, it's more of a `Parser`-level concern than a
`TokenCursor`-level concern. And the struct size reductions are nice.

After this change, `TokenCursor` is as minimal as possible (two fields
and two methods) which is nice.
2023-08-02 10:11:41 +10:00