https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=try-perf 2025-08-14T21:23:05+00:00 2025-08-14T21:23:05+00:00 Josh Triplett josh@joshtriplett.org 2025-08-10T06:56:00+00:00 urn:sha1:354fcf2b52119d938b3181bd6cbc3be1929138df Add infrastructure to apply a derive macro to arguments, consuming and returning a `TokenTree` only. Handle `SyntaxExtensionKind::MacroRules` when expanding a derive, if the macro's kinds support derive. Add tests covering various cases of `macro_rules` derives. Note that due to a pre-existing FIXME in `expand.rs`, derives are re-queued and some errors get emitted twice. Duplicate diagnostic suppression makes them not visible, but the FIXME should still get fixed. 2025-08-12T16:24:45+00:00 Josh Triplett josh@joshtriplett.org 2025-08-09T05:49:57+00:00 urn:sha1:ba231db3f33381f417a94566f043738dcaf60fc3 This eliminates the case in `failed_to_match_macro` to check for a function-like invocation of a macro with no function-like rules. Instead, macro kind mismatches now result in an unresolved macro, and we detect this case in `unresolved_macro_suggestions`, which now carefully distinguishes between a kind mismatch and other errors. This also handles cases of forward-referenced attributes and cyclic attributes. Expand test coverage to include all of these cases. 2025-08-08T18:01:12+00:00 Josh Triplett josh@joshtriplett.org 2025-07-11T08:40:12+00:00 urn:sha1:34be8abb70d1f3247fd7907b6112934742e0abdc Add infrastructure to apply an attribute macro given argument tokens and body tokens. Teach the resolver to consider `macro_rules` macros when looking for an attribute via a path. This does not yet handle local `macro_rules` attributes. 2025-08-08T18:01:12+00:00 Josh Triplett josh@joshtriplett.org 2025-08-08T17:38:27+00:00 urn:sha1:0cc0b11cceae9bbb39bfb9b267e79b05c0d061c1 Add a FIXME for moving this error earlier. 2025-08-08T18:00:54+00:00 Josh Triplett josh@joshtriplett.org 2025-07-06T22:15:01+00:00 urn:sha1:bad0d45b2dc2b2be36e9e82604a6c3dd95dba08a This handles various kinds of errors, but does not allow applying the attributes yet. This adds the feature gate `macro_attr`. 2025-07-05T23:23:13+00:00 Josh Triplett josh@joshtriplett.org 2025-07-04T08:22:37+00:00 urn:sha1:63cfb3af37d74d312829d4e260e03128eb7e3f27 The MBE parser checks rules at initial parse time to see if their RHS has `compile_error!` in it, and returns a list of rule indexes and LHS spans that don't map to `compile_error!`, for use in unused macro rule checking. Instead, have the unused macro rule reporting ask the macro for the rule to report, and let the macro check at that time. That avoids checking rules unless they're unused. In the process, refactor the data structure used to store macro rules, to group the LHS and RHS (and LHS span) of each rule together, and refactor the unused rule tracking to only track rule indexes. This ends up being a net simplification, and reduction in code size. 2025-06-26T22:20:42+00:00 Josh Triplett josh@joshtriplett.org 2025-06-26T21:19:15+00:00 urn:sha1:6c04e0a7aeeee15fc11759dd563aecfe6df194a0 The `macro_rules!` parser was written to match the series of rules using the macros-by-example (MBE) engine and a hand-written equivalent of the left-hand side of a MBE macro. This was complex to read, difficult to extend, and produced confusing error messages. Because it was using the MBE engine, any parse failure would be reported as if some macro was being applied to the `macro_rules!` invocation itself; for instance, errors would talk about "macro invocation", "macro arguments", and "macro call", when they were actually about the macro *definition*. And in practice, the `macro_rules!` parser only used the MBE engine to extract the left-hand side and right-hand side of each rule as a token tree, and then parsed the rest using a separate parser. Rewrite it to parse the series of rules using a simple loop, instead. This makes it more extensible in the future, and improves error messages. For instance, omitting a semicolon between rules will result in "expected `;`" and "unexpected token", rather than the confusing "no rules expected this token in macro call". This work was greatly aided by pair programming with Vincenzo Palazzo and Eric Holk. 2025-06-24T08:37:36+00:00 Trevor Gross tmgross@umich.edu 2025-06-18T02:15:38+00:00 urn:sha1:b9e9be38c01104dd7e1a23995ef89995357bd35b 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-04-20T21:35:56+00:00 Nicholas Nethercote n.nethercote@gmail.com 2025-04-16T06:13:50+00:00 urn:sha1:bf8ce32558a4657d077a6761eaa293d0645c2e16 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-02T05:16:49+00:00 Nicholas Nethercote n.nethercote@gmail.com 2024-05-15T23:22:37+00:00 urn:sha1:4d8f7577b5f2f7c72d1e258c07b882d0afcf0956