about summary refs log tree commit diff
path: root/compiler/rustc_parse/src/parser/item.rs
AgeCommit message (Collapse)AuthorLines
2024-07-29Mark Parser::eat/check methods as must_useMichael Goulet-3/+4
2024-07-29Reformat `use` declarations.Nicholas Nethercote-12/+12
The previous commit updated `rustfmt.toml` appropriately. This commit is the outcome of running `x fmt --all` with the new formatting options.
2024-07-26Improve error message for `extern "C" unsafe fn()`Tamme Dittrich-3/+6
This was handled correctly already for `extern unsafe fn()`. Co-authored-by: Folkert <folkert@folkertdev.nl>
2024-07-25Fix a span error when parsing a wrong param of function.surechen-1/+8
fixes #128042
2024-07-19Rollup merge of #127350 - veera-sivarajan:bugfix-126311, r=lcnrMatthias Krüger-28/+96
Parser: Suggest Placing the Return Type After Function Parameters Fixes #126311 This PR suggests placing the return type after the function parameters when it's misplaced after a `where` clause. This also tangentially improves diagnostics for cases like [this](https://github.com/veera-sivarajan/rust/blob/86d6f1312a77997ef994240e716288d61a343a6d/tests/ui/parser/issues/misplaced-return-type-without-where-issue-126311.rs#L1C1-L1C28) and adds doc comments for `parser::AllowPlus`.
2024-07-18Parser: Suggest Placing the Return Type After Function ParametersVeera-28/+96
2024-07-18Remove `TrailingToken`.Nicholas Nethercote-14/+11
It's used in `Parser::collect_tokens_trailing_token` to decide whether to capture a trailing token. But the callers actually know whether to capture a trailing token, so it's simpler for them to just pass in a bool. Also, the `TrailingToken::Gt` case was weird, because it didn't result in a trailing token being captured. It could have been subsumed by the `TrailingToken::MaybeComma` case, and it effectively is in the new code.
2024-07-17Rollup merge of #127806 - nnethercote:parser-improvements, r=spastorinoTrevor Gross-47/+32
Some parser improvements I was looking closely at attribute handling in the parser while debugging some issues relating to #124141, and found a few small improvements. ``@spastorino``
2024-07-16Inline `Parser::parse_item_common_`.Nicholas Nethercote-43/+32
It has a single call site, it isn't that big, and its name is confusingly similar to `Parser::parse_item_common`.
2024-07-16Remove an unnecessary `?`.Nicholas Nethercote-8/+4
2024-07-15Rollup merge of #127407 - estebank:parser-suggestions, r=oli-obkMatthias Krüger-1/+5
Make parse error suggestions verbose and fix spans Go over all structured parser suggestions and make them verbose style. When suggesting to add or remove delimiters, turn them into multiple suggestion parts.
2024-07-12Make parse error suggestions verbose and fix spansEsteban Küber-1/+5
Go over all structured parser suggestions and make them verbose style. When suggesting to add or remove delimiters, turn them into multiple suggestion parts.
2024-07-12Auto merge of #127382 - estebank:const-let, r=compiler-errorsbors-1/+1
Use verbose style when suggesting changing `const` with `let`
2024-07-11Use verbose style when suggesting changing `const` with `let`Esteban Küber-1/+1
2024-07-11check is_ident before parse_identtrevyn-2/+2
2024-07-08Add suggestions for possible missing `fn`, `struct`, or `enum` keywordstrevyn-49/+63
2024-06-20StaticForeignItem and StaticItem are the sameMichael Goulet-1/+1
2024-06-20Introduce `can_begin_string_literal`.Nicholas Nethercote-2/+2
We currently use `can_begin_literal_maybe_minus` in a couple of places where only string literals are allowed. This commit introduces a more specific function, which makes things clearer. It doesn't change behaviour because the two functions affected (`is_unsafe_foreign_mod` and `check_keyword_case`) are always followed by a call to `parse_abi`, which checks again for a string literal.
2024-06-19Rollup merge of #124135 - petrochenkov:deleglob, r=fmease许杰友 Jieyou Xu (Joe)-5/+19
delegation: Implement glob delegation Support delegating to all trait methods in one go. Overriding globs with explicit definitions is also supported. The implementation is generally based on the design from https://github.com/rust-lang/rfcs/pull/3530#issuecomment-2020869823, but unlike with list delegation in https://github.com/rust-lang/rust/pull/123413 we cannot expand glob delegation eagerly. We have to enqueue it into the queue of unexpanded macros (most other macros are processed this way too), and then a glob delegation waits in that queue until its trait path is resolved, and enough code expands to generate the identifier list produced from the glob. Glob delegation is only allowed in impls, and can only point to traits. Supporting it in other places gives very little practical benefit, but significantly raises the implementation complexity. Part of https://github.com/rust-lang/rust/issues/118212.
2024-06-18Remove redundant argument from `subdiagnostic` methodOli Scherer-8/+5
2024-06-17Rework precise capturing syntaxMichael Goulet-1/+1
2024-06-14delegation: Implement glob delegationVadim Petrochenkov-5/+19
2024-06-07Rollup merge of #126052 - nnethercote:rustc_parse-more-cleanups, r=spastorinoMatthias Krüger-2/+2
More `rustc_parse` cleanups Following on from #125815. r? `@spastorino`
2024-06-06Reduce `pub` exposure.Nicholas Nethercote-2/+2
2024-06-04Add safe/unsafe to static inside extern blocksSantiago Pastorino-5/+13
2024-06-04Handle safety keyword for extern block inner itemsSantiago Pastorino-2/+19
2024-05-23Remove `#[macro_use] extern crate tracing` from `rustc_parse`.Nicholas Nethercote-0/+1
2024-05-20Fix parsing of erroneously placed semicolonsardi-3/+9
2024-05-18Auto merge of #125077 - spastorino:add-new-fnsafety-enum2, r=jackh726bors-23/+23
Rename Unsafe to Safety Alternative to #124455, which is to just have one Safety enum to use everywhere, this opens the posibility of adding `ast::Safety::Safe` that's useful for unsafe extern blocks. This leaves us today with: ```rust enum ast::Safety { Unsafe(Span), Default, // Safe (going to be added for unsafe extern blocks) } enum hir::Safety { Unsafe, Safe, } ``` We would convert from `ast::Safety::Default` into the right Safety level according the context.
2024-05-18Rollup merge of #125117 - dev-ardi:improve-parser, r=wesleywiser,fmeaseMatthias Krüger-30/+26
Improve parser Fixes #124935. - Add a few more help diagnostics to incorrect semicolons - Overall improved that function - Addded a few comments - Renamed diff_marker fns to git_diff_marker
2024-05-17Rename Unsafe to SafetySantiago Pastorino-23/+23
2024-05-17use signature name for argardi-2/+2
2024-05-17s/(Ident, ItemKind)/ItemInfo/ardi-2/+2
2024-05-17Clarify that the diff_marker is talking about version control systemardi-24/+20
conflicts specifically and a few more improvements.
2024-05-15delegation: Implement list delegationVadim Petrochenkov-8/+23
```rust reuse prefix::{a, b, c} ```
2024-05-14improve maybe_consume_incorrect_semicolonardi-2/+2
2024-05-13Remove a `Span` from `TokenKind::Interpolated`.Nicholas Nethercote-1/+1
This span records the declaration of the metavariable in the LHS of the macro. It's used in a couple of error messages. Unfortunately, it gets in the way of the long-term goal of removing `TokenKind::Interpolated`. So this commit removes it, which degrades a couple of (obscure) error messages but makes things simpler and enables the next commit.
2024-05-09Add `ErrorGuaranteed` to `Recovered::Yes` and use it more.Nicholas Nethercote-13/+11
The starting point for this was identical comments on two different fields, in `ast::VariantData::Struct` and `hir::VariantData::Struct`: ``` // FIXME: investigate making this a `Option<ErrorGuaranteed>` recovered: bool ``` I tried that, and then found that I needed to add an `ErrorGuaranteed` to `Recovered::Yes`. Then I ended up using `Recovered` instead of `Option<ErrorGuaranteed>` for these two places and elsewhere, which required moving `ErrorGuaranteed` from `rustc_parse` to `rustc_ast`. This makes things more consistent, because `Recovered` is used in more places, and there are fewer uses of `bool` and `Option<ErrorGuaranteed>`. And safer, because it's difficult/impossible to set `recovered` to `Recovered::Yes` without having emitted an error.
2024-05-08Rollup merge of #123344 - pietroalbini:pa-unused-imports, r=NilstriebMatthias Krüger-2/+6
Remove braces when fixing a nested use tree into a single item [Back in 2019](https://github.com/rust-lang/rust/pull/56645) I added rustfix support for the `unused_imports` lint, to automatically remove them when running `cargo fix`. For the most part this worked great, but when removing all but one childs of a nested use tree it turned `use foo::{Unused, Used}` into `use foo::{Used}`. This is slightly annoying, because it then requires you to run `rustfmt` to get `use foo::Used`. This PR automatically removes braces and the surrouding whitespace when all but one child of a nested use tree are unused. To get it done I had to add the span of the nested use tree to the AST, and refactor a bit the code I wrote back then. A thing I noticed is, there doesn't seem to be any `//@ run-rustfix` test for fixing the `unused_imports` lint. I created a test in `tests/suggestions` (is that the right directory?) that for now tests just what I added in the PR. I can followup in a separate PR to add more tests for fixing `unused_lints`. This PR is best reviewed commit-by-commit.
2024-04-29Add StaticForeignItem and use it on ForeignItemKindSantiago Pastorino-1/+5
2024-04-23delegation: Support renamingVadim Petrochenkov-5/+5
2024-04-17Rename `BindingAnnotation` to `BindingMode`Jules Bertholet-1/+1
2024-04-17Rollup merge of #124051 - dtolnay:emptyset, r=compiler-errorsMatthias Krüger-1/+1
Fix empty-set symbol in comments The symbol in the original code is U+00D8 "LATIN CAPITAL LETTER O WITH STROKE" (https://en.wikipedia.org/wiki/%C3%98) which is an uppercase letter in Danish, Norwegian, Faroese, and Southern Sámi alphabets. The symbol that was intended is U+2205 "EMPTY SET" (https://en.wikipedia.org/wiki/Empty_set#Notation). | Before | After | |---|---| | ![Screenshot from 2024-04-16 18-25-01](https://github.com/rust-lang/rust/assets/1940490/9b8b0624-cfa5-4b89-84e5-4c2b39c2cb8f) | ![Screenshot from 2024-04-16 18-25-05](https://github.com/rust-lang/rust/assets/1940490/6f6b34c3-0e47-4ba0-856d-be1dc164c94c) |
2024-04-17Rollup merge of #122813 - nnethercote:nicer-quals, r=compiler-errorsMatthias Krüger-5/+2
Qualifier tweaking Adding and removing qualifiers in some cases that make things nicer. Details in individual commits. r? `@compiler-errors`
2024-04-16Fix empty-set symbol in commentsDavid Tolnay-1/+1
2024-04-16Auto merge of #123468 - compiler-errors:precise-capturing, r=oli-obkbors-1/+1
Implement syntax for `impl Trait` to specify its captures explicitly (`feature(precise_capturing)`) Implements `impl use<'a, 'b, T, U> Sized` syntax that allows users to explicitly list the captured parameters for an opaque, rather than inferring it from the opaque's bounds (or capturing *all* lifetimes under 2024-edition capture rules). This allows us to exclude some implicit captures, so this syntax may be used as a migration strategy for changes due to #117587. We represent this list of captured params as `PreciseCapturingArg` in AST and HIR, resolving them between `rustc_resolve` and `resolve_bound_vars`. Later on, we validate that the opaques only capture the parameters in this list. We artificially limit the feature to *require* mentioning all type and const parameters, since we don't currently have support for non-lifetime bivariant generics. This can be relaxed in the future. We also may need to limit this to require naming *all* lifetime parameters for RPITIT, since GATs have no variance. I have to investigate this. This can also be relaxed in the future. r? `@oli-obk` Tracking issue: - https://github.com/rust-lang/rust/issues/123432
2024-04-16Avoid unnecessary `rustc_span::DUMMY_SP` usage.Nicholas Nethercote-5/+2
In some cases `DUMMY_SP` is already imported. In other cases this commit adds the necessary import, in files where `DUMMY_SP` is used more than once.
2024-04-15Parsing , pre-lowering support for precise capturesMichael Goulet-1/+1
2024-04-14store the span of the nested part of the use tree in the astPietro Albini-2/+6
2024-04-04Rename ModSep to PathSepLeón Orell Valerian Liehr-5/+5