summary refs log tree commit diff
path: root/compiler/rustc_parse/src/parser/item.rs
AgeCommit message (Collapse)AuthorLines
2024-08-28Rollup merge of #129667 - dev-ardi:rustc_driver-cleanup, r=michaelwoeristerMatthias Krüger-1/+3
Rustc driver cleanup This adds a few comments to the driver to clarify a bit what's happening and does some cleanup.
2024-08-28clarify what term can beOrion Gonzalez-1/+3
2024-08-21Use bool in favor of Option<()> for diagnosticsMichael Goulet-2/+2
2024-08-16Overhaul token collection.Nicholas Nethercote-73/+73
This commit does the following. - Renames `collect_tokens_trailing_token` as `collect_tokens`, because (a) it's annoying long, and (b) the `_trailing_token` bit is less accurate now that its types have changed. - In `collect_tokens`, adds a `Option<CollectPos>` argument and a `UsePreAttrPos` in the return type of `f`. These are used in `parse_expr_force_collect` (for vanilla expressions) and in `parse_stmt_without_recovery` (for two different cases of expression statements). Together these ensure are enough to fix all the problems with token collection and assoc expressions. The changes to the `stringify.rs` test demonstrate some of these. - Adds a new test. The code in this test was causing an assertion failure prior to this commit, due to an invalid `NodeRange`. The extra complexity is annoying, but necessary to fix the existing problems.
2024-08-16Convert a bool to `Trailing`.Nicholas Nethercote-10/+11
This pre-existing type is suitable for use with the return value of the `f` parameter in `collect_tokens_trailing_token`. The more descriptive name will be useful because the next commit will add another boolean value to the return value of `f`.
2024-08-14Use `impl PartialEq<TokenKind> for Token` more.Nicholas Nethercote-19/+19
This lets us compare a `Token` with a `TokenKind`. It's used a lot, but can be used even more, avoiding the need for some `.kind` uses.
2024-08-07Use more slice patterns inside the compilerLeón Orell Valerian Liehr-3/+2
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) |