about summary refs log tree commit diff
path: root/compiler/rustc_expand/src/mbe/macro_check.rs
AgeCommit message (Collapse)AuthorLines
2025-09-25mbe: macro_check: Fix function comments referencing non-existent parametersJosh Triplett-7/+4
Several functions had comments referencing a non-existent `valid` parameter. Remove those. The `guar` parameter that handles errors is already documented. In the process, remove another duplicate reference to an already-documented parameter (`binders`).
2025-09-14Move more early buffered lints to dyn lint diagnostics (1/N)León Orell Valerian Liehr-15/+30
2025-08-12mbe: Rename macro parsing state names to use `Bang` instead of `Not`Josh Triplett-9/+9
The use of `Not` to describe the `!` in `macro_rules!` reads confusingly, and also results in search collisions with the diagnostic structure `MacroRulesNot` elsewhere in the compiler. Rename it to use the more conventional `Bang` for `!`.
2025-08-08mbe: Parse macro attribute rulesJosh Triplett-1/+5
This handles various kinds of errors, but does not allow applying the attributes yet. This adds the feature gate `macro_attr`.
2025-06-26mbe: Fold calls to `check_meta_variables` into the parser loopJosh Triplett-16/+7
2025-06-24mbe: Clean up code with non-optional `NonterminalKind`Trevor Gross-10/+2
Since [1], the fragment specifier is unconditionally required in all editions. This means `NonTerminalKind` no longer needs to be optional, as we can reject this code during the expansion of `macro_rules!` rather than handling it throughout the code. Do this cleanup here. [1]: https://github.com/rust-lang/rust/pull/128425
2025-06-12Make `missing_fragment_specifier` an unconditional errorTrevor Gross-19/+6
This was attempted in [1] then reverted in [2] because of fallout. Recently, this was made an edition-dependent error in [3]. Make missing fragment specifiers an unconditional error again. [1]: https://github.com/rust-lang/rust/pull/75516 [2]: https://github.com/rust-lang/rust/pull/80210 [3]: https://github.com/rust-lang/rust/pull/128006
2025-03-03Rename `ast::TokenKind::Not` as `ast::TokenKind::Bang`.Nicholas Nethercote-1/+1
For consistency with `rustc_lexer::TokenKind::Bang`, and because other `ast::TokenKind` variants generally have syntactic names instead of semantic names (e.g. `Star` and `DotDot` instead of `Mul` and `Range`).
2024-12-18Re-export more `rustc_span::symbol` things from `rustc_span`.Nicholas Nethercote-2/+1
`rustc_span::symbol` defines some things that are re-exported from `rustc_span`, such as `Symbol` and `sym`. But it doesn't re-export some closely related things such as `Ident` and `kw`. So you can do `use rustc_span::{Symbol, sym}` but you have to do `use rustc_span::symbol::{Ident, kw}`, which is inconsistent for no good reason. This commit re-exports `Ident`, `kw`, and `MacroRulesNormalizedIdent`, and changes many `rustc_span::symbol::` qualifiers in `compiler/` to `rustc_span::`. This is a 200+ net line of code reduction, mostly because many files with two `use rustc_span` items can be reduced to one.
2024-10-01Stabilize expr_2021 fragment in all editionsEric Holk-2/+2
Co-authored-by: Michael Goulet <michael@errs.io> Co-authored-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
2024-09-22Reformat using the new identifier sorting from rustfmtMichael Goulet-2/+2
2024-07-29Reformat `use` declarations.Nicholas Nethercote-7/+5
The previous commit updated `rustfmt.toml` appropriately. This commit is the outcome of running `x fmt --all` with the new formatting options.
2024-07-27Make `missing_fragment_specifier` an error in edition 2024Trevor Gross-6/+17
`missing_fragment_specifier` has been a future compatibility warning since 2017. Uplifting it to an unconditional hard error was attempted in 2020, but eventually reverted due to fallout. Make it an error only in edition >= 2024, leaving the lint for older editions. This change will make it easier to support more macro syntax that relies on usage of `$`. Fixes <https://github.com/rust-lang/rust/issues/40107>
2024-07-19Allow concat in repetitionsCaio-4/+4
2024-06-20Add blank lines after module-level `//!` comments.Nicholas Nethercote-0/+1
Most modules have such a blank line, but some don't. Inserting the blank line makes it clearer that the `//!` comments are describing the entire module, rather than the `use` declaration(s) that immediately follows.
2024-06-18Prefer `dcx` methods over fields or fields' methodsOli Scherer-5/+5
2024-05-21Rename buffer_lint_with_diagnostic to buffer_lintXiretza-2/+2
2024-05-21Convert uses of BuiltinLintDiag::Normal to custom variantsXiretza-16/+10
This ensures all diagnostic messages are created at diagnostic emission time, making them translatable.
2024-03-05Rename `DiagnosticMessage` as `DiagMessage`.Nicholas Nethercote-2/+2
2024-03-05Rename all `ParseSess` variables/fields/lifetimes as `psess`.Nicholas Nethercote-45/+46
Existing names for values of this type are `sess`, `parse_sess`, `parse_session`, and `ps`. `sess` is particularly annoying because that's also used for `Session` values, which are often co-located, and it can be difficult to know which type a value named `sess` refers to. (That annoyance is the main motivation for this change.) `psess` is nice and short, which is good for a name used this much. The commit also renames some `parse_sess_created` values as `psess_created`.
2024-02-25Add `ErrorGuaranteed` to `ast::ExprKind::Err`Lieselotte-30/+32
2024-02-20Add newtype for raw identsclubby789-2/+2
2023-12-18Rename `ParseSess::span_diagnostic` as `ParseSess::dcx`.Nicholas Nethercote-6/+5
2023-12-11Add spacing information to delimiters.Nicholas Nethercote-6/+6
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-11-21Fix `clippy::needless_borrow` in the compilerNilstrieb-1/+1
`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-07-30inline format!() args up to and including rustc_middleMatthias Krüger-2/+2
2023-05-16Avoid `&format("...")` calls in error message code.Nicholas Nethercote-4/+9
Error message all end up passing into a function as an `impl Into<{D,Subd}iagnosticMessage>`. If an error message is creatd as `&format("...")` that means we allocate a string (in the `format!` call), then take a reference, and then clone (allocating again) the reference to produce the `{D,Subd}iagnosticMessage`, which is silly. This commit removes the leading `&` from a lot of these cases. This means the original `String` is moved into the `{D,Subd}iagnosticMessage`, avoiding the double allocations. This requires changing some function argument types from `&str` to `String` (when all arguments are `String`) or `impl Into<{D,Subd}iagnosticMessage>` (when some arguments are `String` and some are `&str`).
2023-04-25Fix static string lintsclubby789-4/+2
2023-01-17`rustc_expand`: remove `ref` patternsMaybe Waffle-5/+5
2022-12-18don't restuct references just to reborrowMatthias Krüger-2/+2
2022-05-02fix most compiler/ doctestsElliot Roberts-4/+4
2022-04-28rustc_ast: Harmonize delimiter naming with `proc_macro::Delimiter`Vadim Petrochenkov-4/+4
2022-04-13couple of clippy::complexity fixesMatthias Krüger-1/+1
2022-04-09expand: Remove `ParseSess::missing_fragment_specifiers`Vadim Petrochenkov-2/+13
It was used for deduplicating some errors for legacy code which are mostly deduplicated even without that, but at cost of global mutable state, which is not a good tradeoff.
2022-04-09Remove explicit delimiter token trees from `Delimited`.Nicholas Nethercote-11/+5
They were introduced by the final commit in #95159 and gave a performance win. But since the introduction of `MatcherLoc` they are no longer needed. This commit reverts that change, making the code a bit simpler.
2022-04-05errors: implement fallback diagnostic translationDavid Wood-4/+4
This commit updates the signatures of all diagnostic functions to accept types that can be converted into a `DiagnosticMessage`. This enables existing diagnostic calls to continue to work as before and Fluent identifiers to be provided. The `SessionDiagnostic` derive just generates normal diagnostic calls, so these APIs had to be modified to accept Fluent identifiers. In addition, loading of the "fallback" Fluent bundle, which contains the built-in English messages, has been implemented. Each diagnostic now has "arguments" which correspond to variables in the Fluent messages (necessary to render a Fluent message) but no API for adding arguments has been added yet. Therefore, diagnostics (that do not require interpolation) can be converted to use Fluent identifiers and will be output as before.
2022-04-05span: move `MultiSpan`David Wood-1/+2
`MultiSpan` contains labels, which are more complicated with the introduction of diagnostic translation and will use types from `rustc_errors` - however, `rustc_errors` depends on `rustc_span` so `rustc_span` cannot use types like `DiagnosticMessage` without dependency cycles. Introduce a new `rustc_error_messages` crate that can contain `DiagnosticMessage` and `MultiSpan`. Signed-off-by: David Wood <david.wood@huawei.com>
2022-03-23Eliminate `TokenTreeOrTokenTreeSlice`.Nicholas Nethercote-5/+11
As its name suggests, `TokenTreeOrTokenTreeSlice` is either a single `TokenTree` or a slice of them. It has methods `len` and `get_tt` that let it be treated much like an ordinary slice. The reason it isn't an ordinary slice is that for `TokenTree::Delimited` the open and close delimiters are represented implicitly, and when they are needed they are constructed on the fly with `Delimited::{open,close}_tt`, rather than being present in memory. This commit changes `Delimited` so the open and close delimiters are represented explicitly. As a result, `TokenTreeOrTokenTreeSlice` is no longer needed and `MatcherPos` and `MatcherTtFrame` can just use an ordinary slice. `TokenTree::{len,get_tt}` are also removed, because they were only needed to support `TokenTreeOrTokenTreeSlice`. The change makes the code shorter and a little bit faster on benchmarks that use macro expansion heavily, partly because `MatcherPos` is a lot smaller (less data to `memcpy`) and partly because ordinary slice operations are faster than `TokenTreeOrTokenTreeSlice::{len,get_tt}`.
2022-03-14Fix remaining meta-variable expression TODOsCaio-2/+6
2022-03-09Implement macro meta-variable expressionsCaio-0/+4
2021-03-26Use iter::zip in compiler/Josh Stone-1/+3
2020-10-30Fix some more clippy warningsJoshua Nelson-4/+1
2020-08-30mv compiler to compiler/mark-0/+633