rust_2024_incompatible_pat bad suggestion with proc-macro when brace comes from input

[ehuss]

When a proc-macro generates code, and the opening brace of a pattern from that code comes from the input, then the compiler thinks that the pattern is a 2024 pattern, and thus enforces the new pattern rules using the local edition, not the edition from the proc-macro.

There are two consequences:

1. This is incompatible with supporting macros that are on different editions.
2. It generates an invalid suggestion.

Example of the bad suggestion might be:

#[derive(my_macro)]
struct S {
    f1: i32
}

will give a suggestion to modify the struct to add an & which is invalid syntax like this:

struct &S {
    f1: i32
}

This was seen with swc_macros_common here where it uses the brace token from the input.

One option is to change this in the macro to generate a new token with the correct span information.

I'm also wondering if there are options for changing the ways tokens are processed from proc-macros to avoid this altogether.

Meta

rustc --version --verbose:

rustc 1.84.0-nightly (81eef2d36 2024-11-11)
binary: rustc
commit-hash: 81eef2d362a6f03db6f8928f82d94298d31eb81b
commit-date: 2024-11-11
host: aarch64-unknown-linux-gnu
release: 1.84.0-nightly
LLVM version: 19.1.3

[traviscross]

@Nadrieril: What do you think?

[Nadrieril]

That's a general issue with macros isn't it? Suggestions often don't make sense when we reuse tokens for different purposes. Is the ergonomics-2024 lint doing something particularly painful here?

[ehuss]

Just adding my personal notes here. I'm currently uncertain how I want to track this general issue of proc-macros re-spanning the input. It looks like it is fairly common for proc-macros to do that in order to provide better error messages (so that it points at the user's code in the correct place). Unfortunately this often results in the wrong edition hygiene, and causes the diagnostics to give invalid suggestions.

Another example is darling, which uses quote_spanned (here) with a span from the user's input. This trips the if_let_rescope lint, causing a corrupted suggestion around the attribute.

I'm finding the use of quote_spanned quite common.

In this particular case, it fortunately fails to apply, but unfortunately gives a scary error message that tells the user to contact us:

The full error message was:

> cannot replace slice of data that was already replaced

This likely indicates a bug in either rustc or cargo itself,
and we would appreciate a bug report! You're likely to see
a number of compiler warnings after this message which cargo
attempted to fix but failed. If you could open an issue at
https://github.com/rust-lang/rust/issues
quoting the full output of this command we'd be very appreciative!
Note that you may be able to make some more progress in the near-term
fixing code with the `--broken-code` flag

---

Other examples:

• zng_app_proc_macros