expand: Stop using nonterminals for passing tokens to attribute and derive macros Make one more step towards fully token-based expansion and fix issues described in https://github.com/rust-lang/rust/issues/72545#issuecomment-640276791. Now `struct S;` is passed to `foo!(struct S;)` and `#[foo] struct S;` in the same way - as a token stream `struct S ;`, rather than a single non-terminal token `NtItem` which is then broken into parts later. The cost is making pretty-printing of token streams less pretty. Some of the pretty-printing regressions will be recovered by keeping jointness with each token, which we will need to do anyway. Unfortunately, this is not exactly the same thing as https://github.com/rust-lang/rust/pull/73102. One more observable effect is how `$crate` is printed in the attribute input. Inside `NtItem` was printed as `crate` or `that_crate`, now as a part of a token stream it's printed as `$crate` (there are good reasons for these differences, see https://github.com/rust-lang/rust/pull/62393 and related PRs). This may break old proc macros (custom derives) written before the main portion of the proc macro API (macros 1.2) was stabilized, those macros did `input.to_string()` and reparsed the result, now that result can contain `$crate` which cannot be reparsed. So, I think we should do this regardless, but we need to run crater first. r? @Aaron1011 |
||
|---|---|---|
| .. | ||
| auxiliary | ||
| attr-without-param.rs | ||
| attr-without-param.stderr | ||
| issue-64682-dropping-first-attrs-in-impl-fns.rs | ||
| param-attrs-2018.rs | ||
| param-attrs-2018.stderr | ||
| param-attrs-allowed.rs | ||
| param-attrs-builtin-attrs.rs | ||
| param-attrs-builtin-attrs.stderr | ||
| param-attrs-cfg.rs | ||
| param-attrs-cfg.stderr | ||
| param-attrs-pretty.rs | ||
| proc-macro-cannot-be-used.rs | ||
| proc-macro-cannot-be-used.stderr | ||