proc_macro API: Expose `macro_rules` hygiene
Proc macros do not have direct access to our oldest and most stable hygiene kind - `macro_rules` hygiene.
To emulate it macro authors have to go through two steps - first generate a temporary `macro_rules` item (using a derive, at least until https://github.com/rust-lang/rust/pull/64035 is merged), then generate a macro call to that item. Popular crates like [proc_macro_hack](https://crates.io/crates/proc-macro-hack) use this trick to generate hygienic identifiers from proc macros.
I'd say that these workarounds with nested macro definitions have more chances to hit some corner cases in our hygiene system, in which we don't have full confidence.
So, let's provide a direct access to `macro_rules` hygiene instead.
This PR does that by adding a new method `Span::mixed_site` (bikeshedding is welcome) in addition to existing `Span::call_site` (stable) and `Span::def_site` (unstable).
Identifiers with this span resolve at def-site in for local variables, labels and `$crate`, and resolve at call-site for everything else, i.e. exactly like identifiers produced by `macro_rules`.
This API addition opens the way to stabilizing proc macros in expression positions (https://github.com/rust-lang/rust/issues/54727), for which use of call-site hygiene or workarounds with temporary items would be quite unfortunate.
(`macro_rules` expanded in expression position, on the other hand, are stable since 1.0 and widely used.)
r? @dtolnay @alexcrichton
Deprecate `#![plugin]` & `#[plugin_registrar]`
This PR deprecates `#![plugin]` and `#[plugin_registrar]`.
~A removal deadline is set: 1.44.0. This will be in 9 months from now and should give everyone who is still relying on the feature ample time to rid themselves of this dependency.~
cc https://github.com/rust-lang/rust/issues/29597
r? @Mark-Simulacrum
Stabilize todo macro
The `todo!` macro is just another name for `unimplemented!`.
Tracking issue: https://github.com/rust-lang/rust/issues/59277
This PR needs a FCP to merge.
r? @withoutboats
It was only used for retreiving edition, which was a bug.
In case of dual proc macros the edition should be taken from the target crate version, like any other metadata.
(Without this commit, you still get an error (a very similar one, at
that), but it complains about use of forward declaration, which is
confusing since people do not necessarily think of `Self` as being
declared at all.)
Update: incorporate review feedback.
Inline `{min,max}_value` even in debug builds
I think it is worth to inline `{min,max}_value` even in debug builds.
See this godbolt link: https://godbolt.org/z/-COkVS
Rollup of 7 pull requests
Successful merges:
- #63678 (Improve HRTB error span when -Zno-leak-check is used)
- #64931 (Reword E0392 slightly)
- #64959 (syntax: improve parameter without type suggestions)
- #64975 (Implement Clone::clone_from for LinkedList)
- #64993 (BacktraceStatus: add Eq impl)
- #64998 (Filter out RLS output directories on tidy runs)
- #65010 (Compare `primary` with maximum of `children`s' line num instead of dropping it)
Failed merges:
r? @ghost
