Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve the error message when forwarding a matched fragment to another macro #110222

Merged
merged 2 commits into from
Apr 12, 2023

Conversation

lovelymono
Copy link
Contributor

@lovelymono lovelymono commented Apr 12, 2023

Adds a link to Forwarding a matched fragment section of the Rust Reference, and suggests a possible fix (using :tt instead in the macro definition).

Also removes typos from the original message, it should be :lifetime instead of $lifetime.

Motivation

When trying to write a macro which uses a literal in the matcher from the outer macro, like the following one, using a fragment specified that isn't one of :ident, :lifetime, or :tt currently results in a hard to understand message.

macro_rules! make_t_for_all_tokens {
    ($($name:literal as $variant:expr,)*) => {
        macro_rules! t {
            $(
                ($name) => {
                    $variant
                };
            )*
        }
    };
}

make_t_for_all_tokens! {
    "fn" as Token::Fn,
    "return" as Token::Return,
    "let" as Token::Let,
}

// This creates
//
// macro_rules! t {
//     ("fn") => {
//         Token::Fn
//     };
//     ("return") => {
//         Token::Return
//     };
//     ("let") => {
//         Token::Let
//     };
// }

t!["fn"];

Before

error: no rules expected the token `"fn"`
   --> src/main.rs:103:10
    |
32  |         macro_rules! t {
    |         -------------- when calling this macro
...
103 |     t!["fn"];
    |        ^^^^ no rules expected this token in macro call
    |
note: while trying to match `"fn"`
   --> src/main.rs:34:6
    |
34  |                   ($name) => {
    |                    ^^^^^
...
58  | / make_t_for_all_tokens! {
59  | |     "fn" as Token::Fn,
60  | |     "return" as Token::Return,
61  | |     "let" as Token::Let,
62  | | }
    | |_- in this macro invocation
    = note: captured metavariables except for `$tt`, `$ident` and `$lifetime` cannot be compared to other tokens
    = note: this error originates in the macro `make_t_for_all_tokens` (in Nightly builds, run with -Z macro-backtrace for more info)

After

error: no rules expected the token `"fn"`
   --> src/main.rs:103:10
    |
32  |         macro_rules! t {
    |         -------------- when calling this macro
...
103 |     t!["fn"];
    |        ^^^^ no rules expected this token in macro call
    |
note: while trying to match `"fn"`
   --> src/main.rs:34:6
    |
34  |                   ($name) => {
    |                    ^^^^^
...
58  | / make_t_for_all_tokens! {
59  | |     "fn" as Token::Fn,
60  | |     "return" as Token::Return,
61  | |     "let" as Token::Let,
62  | | }
    | |_- in this macro invocation
    = note: captured metavariables except for `:tt`, `:ident` and `:lifetime` cannot be compared to other tokens
    = note: see https://doc.rust-lang.org/nightly/reference/macros-by-example.html#forwarding-a-matched-fragment for more information
    = help: try using `:tt` instead in the macro definition
    = note: this error originates in the macro `make_t_for_all_tokens` (in Nightly builds, run with -Z macro-backtrace for more info)

Unresolved questions

  • Preferrably the suggestion should be attached to the $name:literal part of the outer macro, instead of being in the notes section at the end. But I'm not familiar with how the compiler works at all, and I have no idea how to approach this kind of solution.
  • @Nilstrieb raised a question that the suggestion of adding :tt isn't accurate when there's more than tt being matched, for example when the input is an item.

Adds a link to the relevant part of The Rust Reference in the eror
message, and suggests a possible fix (replacing the fragment specifier
with :tt in the macro definition).

Fixes typos in the original message.

Signed-off-by: Lena Milizé <me@lvmn.org>
@rustbot
Copy link
Collaborator

rustbot commented Apr 12, 2023

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @davidtwco (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Apr 12, 2023
compiler/rustc_expand/src/mbe/diagnostics.rs Outdated Show resolved Hide resolved
compiler/rustc_expand/src/mbe/diagnostics.rs Outdated Show resolved Hide resolved
And wrap the link in the diagnostic in angle brackets.

Signed-off-by: Lena Milizé <me@lvmn.org>
@davidtwco
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Apr 12, 2023

📌 Commit 04f20d4 has been approved by davidtwco

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 12, 2023
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 12, 2023
…iaskrgr

Rollup of 8 pull requests

Successful merges:

 - rust-lang#110153 (Fix typos in compiler)
 - rust-lang#110165 (rustdoc: use CSS `overscroll-behavior` instead of JavaScript)
 - rust-lang#110175 (Symbol cleanups)
 - rust-lang#110203 (Remove `..` from return type notation)
 - rust-lang#110205 (rustdoc: make settings radio and checks thicker, less contrast)
 - rust-lang#110222 (Improve the error message when forwarding a matched fragment to another macro)
 - rust-lang#110237 (Split out a separate feature gate for impl trait in associated types)
 - rust-lang#110241 (tidy: Issue an error when UI test limits are too high)

Failed merges:

 - rust-lang#110218 (Remove `ToRegionVid`)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit d54a8ac into rust-lang:master Apr 12, 2023
@rustbot rustbot added this to the 1.70.0 milestone Apr 12, 2023
@lovelymono lovelymono deleted the rustc-expand-mbe-diagnostic branch April 13, 2023 09:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants