rustdoc: Correctly handle built-in compiler proc-macros as proc-macro and not macro #110279
Conversation
|
Failed to set assignee to
|
rustbot
added
S-waiting-on-review
|
I keep forgetting you don't have r+ rights... Let's set @notriddle as reviewer then (but your input is very welcome!). r? @notriddle |
GuillaumeGomez
force-pushed
the
compiler-macro-derive
branch
from
004b312 to
42bbfe5
Compare
| let ty_vis = cx.tcx.visibility(def_id); | ||
| MacroItem(Macro { | ||
| source: display_macro_source(cx, name, macro_def, def_id, ty_vis), | ||
| }) | ||
| } | ||
| ItemKind::Macro(_, macro_kind) => clean_proc_macro(item, &mut name, macro_kind, cx), |
There was a problem hiding this comment.
So as far as I understand we treat non-bang macro declarations (macro or macro_rules!) as proc macros because we assume that they have #[rustc_builtin_macro] on them and since currently there is no way to define attributes and derive macros via declarative macros, right?
Seems fine to me, although that fact could change in the far™ future. If that happened we'd "need" new ItemTypes anyway.
There was a problem hiding this comment.
Yes, as you can see in the test I updated. We'll see if it ever happen but I never heard of it (if you have a link to a discussion about it, I'm very interested!).
There was a problem hiding this comment.
Nothing to link to, no. I faintly remember reading discussions about it someplace sometime ago.
GuillaumeGomez
force-pushed
the
compiler-macro-derive
branch
from
42bbfe5 to
80c4323
Compare
|
Added suggested checks. |
|
@bors r+ rollup |
bors
added
S-waiting-on-bors
…ve, r=notriddle rustdoc: Correctly handle built-in compiler proc-macros as proc-macro and not macro Part of rust-lang#110111. There were actually one issue split in two parts: * Compiler built-in proc-macro were incorrectly considered as macros and not proc-macros. * Re-exports of compiler built-in proc-macros were considering them as macros. Both issues can be fixed by looking at the `MacroKind` variant instead of just relying on information extracted later on. r? `@fmease`
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#109225 (Clarify that RUST_MIN_STACK may be internally cached) - rust-lang#109800 (Improve safe transmute error reporting) - rust-lang#110158 (Remove obsolete test case) - rust-lang#110180 (don't uniquify regions when canonicalizing) - rust-lang#110207 (Assemble `Unpin` candidates specially for generators in new solver) - rust-lang#110276 (Remove all but one of the spans in `BoundRegionKind::BrAnon`) - rust-lang#110279 (rustdoc: Correctly handle built-in compiler proc-macros as proc-macro and not macro) - rust-lang#110298 (Cover edge cases for {f32, f64}.hypot() docs) - rust-lang#110299 (Switch to `EarlyBinder` for `impl_subject` query) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Part of #110111.
There were actually one issue split in two parts:
Both issues can be fixed by looking at the
MacroKindvariant instead of just relying on information extracted later on.r? @fmease