Closed
Description
#![feature(proc_macro, proc_macro_lib)]
extern crate proc_macro;
use proc_macro::TokenStream;
#[proc_macro_derive(Nothing)]
pub fn nothing(_: TokenStream) -> TokenStream {
"".parse().unwrap()
}
#[macro_use]
extern crate nothing_derive;
macro_rules! int {
() => { i32 }
}
#[derive(Nothing)]
struct S {
x: int!(),
}
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
thread 'rustc' panicked at 'visit_mac disabled by default', /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libsyntax/visit.rs:102
note: Run with `RUST_BACKTRACE=1` for a backtrace.
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
dtolnay commentedon Dec 30, 2016
This is a regression from #37614 because it works fine on nightly-2016-11-06 - cc @keeperofdakeys.
keeperofdakeys commentedon Dec 31, 2016
@jseyfried This seems like a simple case of the attribute visitor walking the AST before expansion. I assume we just want to add a simple visit_mac implementation here like the Visitor trait suggests?
For reference:
jseyfried commentedon Dec 31, 2016
@keeperofdakeys Yeah, adding an empty
fn visit_mac
to theVisitor
impl forMarkAttrs
should be sufficient.keeperofdakeys commentedon Dec 31, 2016
If you print the input to the derive function in the above example, you get this:
I can't help but wonder if it would be better to expand the
int!
macro before the derives.Edit: Seems there has previously been some discussion about this #33769 and #34010
Auto merge of #38737 - keeperofdakeys:proc-macro-derive-Dec-16, r=jse…
jseyfried commentedon Jan 2, 2017
@keeperofdakeys (cc @nrc)
Not expanding first can be strictly more powerful -- we can support something like
However, I'm not sure why a
proc_macro_derive
would want to depend on whether the macros in the underlying item have been expanded, so I think forcingproc_macro_derive
s not to depend on this by expanding the underlying item first might be a good idea.Note that we currently "expand"
cfg
andcfg_attr
before beforeproc_macro_derive
s.