about summary refs log tree commit diff
path: root/compiler/rustc_attr_parsing/src
AgeCommit message (Collapse)AuthorLines
2025-06-17implement inline parserJonathan Dönszelmann-1/+4
2025-06-16Port `#[rustc_as_ptr]` to the new attribute systemPavel Grigorenko-0/+24
2025-06-13Rollup merge of #142158 - xizheyin:141617, r=jdonszelmannMatthias Krüger-1/+4
Tracking the old name of renamed unstable library features This PR resolves the first problem of rust-lang/rust#141617 : tracking renamed unstable features. The first commit is to add a ui test, and the second one tracks the changes. I will comment on the code for clarification. r? `@jdonszelmann` There have been a lot of PR's reviewed by you lately, thanks for your time! cc `@jyn514`
2025-06-12Tracking the old name of renamed unstable library attributexizheyin-1/+4
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
2025-06-12remove 'static in some placesJana Dönszelmann-13/+13
2025-06-12add error message for unused duplicateJana Dönszelmann-1/+1
2025-06-12introduce new lint infraJana Dönszelmann-194/+458
lint on duplicates during attribute parsing To do this we stuff them in the diagnostic context to be emitted after hir is constructed
2025-06-12Start using new diagnostic logic on all existing `single` parsersJonathan Dönszelmann-43/+14
2025-06-12introduce duplicate attribute diagnostic logicJana Dönszelmann-17/+112
2025-06-11consistently rename (old) attribute groupsJana Dönszelmann-12/+14
2025-06-11document attribute parsers betterJana Dönszelmann-0/+9
2025-06-06Rollup merge of #142058 - xizheyin:rustc-attr-parsing, r=jdonszelmannMatthias Krüger-37/+37
Clean `rustc_attr_parsing/src/lib.rs` documentation Improves the documentation clarity in `rustc_attr_parsing` by restructuring content with clearer section headers, simplifying explanations of attribute types, making technical descriptions more precise. r? ``@oli-obk``
2025-06-05Clean `rustc_attr_parsing` documentationxizheyin-37/+37
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
2025-06-04Rollup merge of #141271 - nnethercote:attr-streamline, r=jdonszelmannMatthias Krüger-64/+19
Streamline some attr parsing APIs r? ``@jdonszelmann``
2025-05-26Add custom trait for emitting lint within `cfg_matches`Urgau-6/+21
2025-05-26Rollup merge of #140539 - nnethercote:simplify-attribute_groups, r=jdonszelmannJacob Pratt-48/+47
Simplify `attribute_groups` It's more complicated than it needs to be. r? ``@jdonszelmann``
2025-05-24Make #[cfg(version)] respect RUSTC_OVERRIDE_VERSION_STRINGest31-2/+2
2025-05-21Rename `MetaItemParser::path_without_args` as `MetaItemParser::path`.Nicholas Nethercote-13/+13
And avoid the clone.
2025-05-21Remove `MetaItemParser::{path,deconstruct}`.Nicholas Nethercote-15/+7
They're equivalent, and `path` is unused, and `deconstruct` has only one call site outside of `path`.
2025-05-21Remove `MetaItemParser::{word,word_without_args,path_is}`.Nicholas Nethercote-23/+0
They are unused.
2025-05-21Remove an unnecessary lifetime.Nicholas Nethercote-1/+1
2025-05-21collect doc alias as tips during resolutionbohan-1/+33
2025-05-20Remove `MetaItemListParser::all_{word,path}_list`, which are unused.Nicholas Nethercote-14/+0
2025-05-20Avoid `rustc_span::` qualifiers.Nicholas Nethercote-17/+16
In several files they are entirely unnecessary, with the relevant names already imported. And in a few I have added the necessary `use` item.
2025-05-20Fix up some comments.Nicholas Nethercote-16/+15
Some are too long (> 100 chars), some are too short, some are missing full stops, some are missing upper-case letters at the start of sentences.
2025-05-20Simplify `Accepts`.Nicholas Nethercote-10/+7
There only needs to be one `Fn` per symbol, not multiple.
2025-05-20Introduce some typedefs to improve readability.Nicholas Nethercote-6/+10
2025-05-19Rollup merge of #140874 - mejrs:rads, r=WaffleLapkinStuart Cook-2/+2
make `rustc_attr_parsing` less dominant in the rustc crate graph It has/had a glob re-export of `rustc_attr_data_structures`, which is a crate much lower in the graph, and a lot of crates were using it *just* (or *mostly*) for that re-export, while they can rely on `rustc_attr_data_structures` directly. Previous graph: ![graph_1](https://github.com/user-attachments/assets/f4a5f13c-4222-4903-b56d-28c83511fcbd) Graph with this PR: ![graph_2](https://github.com/user-attachments/assets/1e053d9c-75cc-402b-84df-86229c98277a) The first commit keeps the re-export, and just changes the dependency if possible. The second commit is the "breaking change" which removes the re-export, and "explicitly" adds the `rustc_attr_data_structures` dependency where needed. It also switches over some src/tools/*. The second commit is actually a lot more involved than I expected. Please let me know if it's a better idea to back it out and just keep the first commit.
2025-05-18Remove rustc_attr_data_structures re-export from rustc_attr_parsingmejrs-2/+2
2025-05-12update cfg(bootstrap)Pietro Albini-1/+0
2025-05-07Avoid some unwraps.Nicholas Nethercote-36/+45
By using `@` patterns more. Also, use `Symbol` more in a couple of errors to avoid some unnecessary conversions to strings. This even removes a lifetime.
2025-05-07Eliminate `word_or_empty` methods.Nicholas Nethercote-61/+55
To get rid of the `Ident::empty` uses. This requires introducing `PathParser::word_sym`, as an alternative to `PathParser::word`.
2025-04-30Simplify `LazyAttrTokenStream`.Nicholas Nethercote-0/+1
This commit does the following. - Changes it from `Lrc<Box<dyn ToAttrTokenStream>>` to `Lrc<LazyAttrTokenStreamInner>`. - Reworks `LazyAttrTokenStreamImpl` as `LazyAttrTokenStreamInner`, which is a two-variant enum. - Removes the `ToAttrTokenStream` trait and the two impls of it. The recursion limit must be increased in some crates otherwise rustdoc aborts.
2025-04-25Auto merge of #140282 - matthiaskrgr:rollup-g6ze4jj, r=matthiaskrgrbors-1/+1
Rollup of 8 pull requests Successful merges: - #137653 (Deprecate the unstable `concat_idents!`) - #138957 (Update the index of Option to make the summary more comprehensive) - #140006 (ensure compiler existance of tools on the dist step) - #140143 (Move `sys::pal::os::Env` into `sys::env`) - #140202 (Make #![feature(let_chains)] bootstrap conditional in compiler/) - #140236 (norm nested aliases before evaluating the parent goal) - #140257 (Some drive-by housecleaning in `rustc_borrowck`) - #140278 (Don't use item name to look up associated item from trait item) r? `@ghost` `@rustbot` modify labels: rollup
2025-04-25Rollup merge of #140229 - nnethercote:pre-DelimArgs-spacing, r=petrochenkovMatthias Krüger-6/+2
`DelimArgs` tweaks r? `@petrochenkov`
2025-04-23Make #![feature(let_chains)] bootstrap conditional in compiler/est31-1/+1
2025-04-23Use `clone` to clone `DelimArgs` in two places.Nicholas Nethercote-6/+2
2025-04-22Auto merge of #139897 - nnethercote:rm-OpenDelim-CloseDelim, r=petrochenkovbors-3/+1
Remove `token::{Open,Close}Delim` By replacing them with `{Open,Close}{Param,Brace,Bracket,Invisible}`. PR #137902 made `ast::TokenKind` more like `lexer::TokenKind` by replacing the compound `BinOp{,Eq}(BinOpToken)` variants with fieldless variants `Plus`, `Minus`, `Star`, etc. This commit does a similar thing with delimiters. It also makes `ast::TokenKind` more similar to `parser::TokenType`. This requires a few new methods: - `TokenKind::is_{,open_,close_}delim()` replace various kinds of pattern matches. - `Delimiter::as_{open,close}_token_kind` are used to convert `Delimiter` values to `TokenKind`. Despite these additions, it's a net reduction in lines of code. This is because e.g. `token::OpenParen` is so much shorter than `token::OpenDelim(Delimiter::Parenthesis)` that many multi-line forms reduce to single line forms. And many places where the number of lines doesn't change are still easier to read, just because the names are shorter, e.g.: ``` - } else if self.token != token::CloseDelim(Delimiter::Brace) { + } else if self.token != token::CloseBrace { ``` r? `@petrochenkov`
2025-04-21Remove `token::{Open,Close}Delim`.Nicholas Nethercote-3/+1
By replacing them with `{Open,Close}{Param,Brace,Bracket,Invisible}`. PR #137902 made `ast::TokenKind` more like `lexer::TokenKind` by replacing the compound `BinOp{,Eq}(BinOpToken)` variants with fieldless variants `Plus`, `Minus`, `Star`, etc. This commit does a similar thing with delimiters. It also makes `ast::TokenKind` more similar to `parser::TokenType`. This requires a few new methods: - `TokenKind::is_{,open_,close_}delim()` replace various kinds of pattern matches. - `Delimiter::as_{open,close}_token_kind` are used to convert `Delimiter` values to `TokenKind`. Despite these additions, it's a net reduction in lines of code. This is because e.g. `token::OpenParen` is so much shorter than `token::OpenDelim(Delimiter::Parenthesis)` that many multi-line forms reduce to single line forms. And many places where the number of lines doesn't change are still easier to read, just because the names are shorter, e.g.: ``` - } else if self.token != token::CloseDelim(Delimiter::Brace) { + } else if self.token != token::CloseBrace { ```
2025-04-20Remove #[rustc_macro_edition_2021].Mara Bos-22/+0
It was only temporarily used by pin!(), which no longer needs it.
2025-04-18Rollup merge of #139615 - nnethercote:rm-name_or_empty, r=jdonszelmannMatthias Krüger-9/+9
Remove `name_or_empty` Another step towards #137978. r? ``@jdonszelmann``
2025-04-17Auto merge of #139949 - matthiaskrgr:rollup-pxc5tsx, r=matthiaskrgrbors-15/+0
Rollup of 8 pull requests Successful merges: - #138632 (Stabilize `cfg_boolean_literals`) - #139416 (unstable book; document `macro_metavar_expr_concat`) - #139782 (Consistent with treating Ctor Call as Struct in liveness analysis) - #139885 (document RUSTC_BOOTSTRAP, RUSTC_OVERRIDE_VERSION_STRING, and -Z allow-features in the unstable book) - #139904 (Explicitly annotate edition for `unpretty=expanded` and `unpretty=hir` tests) - #139932 (transmutability: Refactor tests for simplicity) - #139944 (Move eager translation to a method on Diag) - #139948 (git: ignore `60600a6fa403216bfd66e04f948b1822f6450af7` for blame purposes) r? `@ghost` `@rustbot` modify labels: rollup
2025-04-17Rollup merge of #138632 - clubby789:stabilize-cfg-boolean-lit, ↵Matthias Krüger-15/+0
r=davidtwco,Urgau,traviscross Stabilize `cfg_boolean_literals` Closes #131204 `@rustbot` labels +T-lang +I-lang-nominated This will end up conflicting with the test in #138293 so whichever doesn't land first will need updating -- # Stabilization Report ## General design ### What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized? [RFC 3695](https://github.com/rust-lang/rfcs/pull/3695), none. ### What behavior are we committing to that has been controversial? Summarize the major arguments pro/con. None ### Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those? None ## Has a call-for-testing period been conducted? If so, what feedback was received? Yes; only positive feedback was received. ## Implementation quality ### Summarize the major parts of the implementation and provide links into the code (or to PRs) Implemented in [#131034](https://github.com/rust-lang/rust/pull/131034). ### Summarize existing test coverage of this feature - [Basic usage, including `#[cfg()]`, `cfg!()` and `#[cfg_attr()]`](https://github.com/rust-lang/rust/blob/6d71251cf9e40326461f90f8ff9a7024706aea87/tests/ui/cfg/true-false.rs) - [`--cfg=true/false` on the command line being accessible via `r#true/r#false`](https://github.com/rust-lang/rust/blob/6d71251cf9e40326461f90f8ff9a7024706aea87/tests/ui/cfg/raw-true-false.rs) - [Interaction with the unstable `#[doc(cfg(..))]` feature](https://github.com/rust-lang/rust/tree/6d71251/tests/rustdoc-ui/cfg-boolean-literal.rs) - [Denying `--check-cfg=cfg(true/false)`](https://github.com/rust-lang/rust/tree/6d71251/tests/ui/check-cfg/invalid-arguments.rs) - Ensuring `--cfg false` on the command line doesn't change the meaning of `cfg(false)`: `tests/ui/cfg/cmdline-false.rs` - Ensuring both `cfg(true)` and `cfg(false)` on the same item result in it being disabled: `tests/ui/cfg/both-true-false.rs` ### What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking? The above mentioned issue; it should not block as it interacts with another unstable feature. ### What FIXMEs are still in the code for that feature and why is it ok to leave them there? None ### Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization - `@clubby789` (RFC) - `@Urgau` (Implementation in rustc) ### Which tools need to be adjusted to support this feature. Has this work been done? `rustdoc`'s unstable`#[doc(cfg(..)]` has been updated to respect it. `cargo` has been updated with a forward compatibility lint to enable supporting it in cargo once stabilized. ## Type system and execution rules ### What updates are needed to the reference/specification? (link to PRs when they exist) A few lines to be added to the reference for configuration predicates, specified in the RFC.
2025-04-17Replace infallible `name_or_empty` methods with fallible `name` methods.Nicholas Nethercote-9/+9
I'm removing empty identifiers everywhere, because in practice they always mean "no identifier" rather than "empty identifier". (An empty identifier is impossible.) It's better to use `Option` to mean "no identifier" because you then can't forget about the "no identifier" possibility. Some specifics: - When testing an attribute for a single name, the commit uses the `has_name` method. - When testing an attribute for multiple names, the commit uses the new `has_any_name` method. - When using `match` on an attribute, the match arms now have `Some` on them. In the tests, we now avoid printing empty identifiers by not printing the identifier in the `error:` line at all, instead letting the carets point out the problem.
2025-04-17Rollup merge of #139084 - petrochenkov:transpaque, r=davidtwcoMatthias Krüger-1/+1
hygiene: Rename semi-transparent to semi-opaque "Semi-transparent" is just too damn long for a name, especially when used multiple times on a single line, it bothered me when working on #139083. An optimist sees a macro as semi-opaque, a pessimist sees it as semi-transparent. Or is it the other way round?
2025-04-03Stabilize `cfg_boolean_literals`clubby789-15/+0
2025-04-02Remove `recursion_limit` increases.Nicholas Nethercote-1/+0
These are no longer needed now that `Nonterminal` is gone.
2025-04-02Remove `TokenStream::flattened` and `InvisibleOrigin::FlattenToken`.Nicholas Nethercote-1/+1
They are no longer needed. This does slightly worsen the error message for a single test, but that test contains code that is so badly broken that I'm not worried about it.
2025-04-02Remove `NtBlock`, `Nonterminal`, and `TokenKind::Interpolated`.Nicholas Nethercote-19/+1
`NtBlock` is the last remaining variant of `Nonterminal`, so once it is gone then `Nonterminal` can be removed as well.
2025-03-31hygiene: Rename semi-transparent to semi-opaqueVadim Petrochenkov-1/+1
The former is just too long, see the examples in `hygiene.rs`