Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proc_macro does not support type macros #38706

Closed
dtolnay opened this issue Dec 30, 2016 · 5 comments
Closed

proc_macro does not support type macros #38706

dtolnay opened this issue Dec 30, 2016 · 5 comments
Assignees
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️

Comments

@dtolnay
Copy link
Member

dtolnay commented Dec 30, 2016

#![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.
@frewsxcv frewsxcv added A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ labels Dec 30, 2016
@dtolnay
Copy link
Member Author

dtolnay commented Dec 30, 2016

This is a regression from #37614 because it works fine on nightly-2016-11-06 - cc @keeperofdakeys.

@jseyfried jseyfried self-assigned this Dec 30, 2016
@keeperofdakeys
Copy link
Contributor

@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:

thread 'rustc' panicked at 'visit_mac disabled by default', src/libsyntax/visit.rs:102
stack backtrace:
   1:     0x7f6603f90d5e - std::sys::imp::backtrace::tracing::imp::write::h518610b6cdcee611
                        at /home/user/work/rust/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:42
   2:     0x7f6603fc043c - std::panicking::default_hook::{{closure}}::h73d8acc8aa188e9c
                        at /home/user/work/rust/src/libstd/panicking.rs:351
   3:     0x7f6603fbff30 - std::panicking::default_hook::hb346e96e14e8e6ac
                        at /home/user/work/rust/src/libstd/panicking.rs:361
   4:     0x7f6603fc10d5 - std::panicking::rust_panic_with_hook::h4d032fa503172e37
                        at /home/user/work/rust/src/libstd/panicking.rs:555
   5:     0x7f6600b5cd83 - std::panicking::begin_panic::h6d4fab3dfce17e2b
                        at /home/user/work/rust/src/libstd/panicking.rs:517
   6:     0x7f6600c20dd9 - syntax::visit::Visitor::visit_mac::he1ff4bc18d7cfa28
                        at /home/user/work/rust/<panic macros>:3
   7:     0x7f6600c2204c - syntax::visit::walk_ty::hc237d852c17c3cad
                        at /home/user/work/rust/src/libsyntax/visit.rs:364
   8:     0x7f6600c20ccc - syntax::visit::Visitor::visit_ty::hbfa34222ed9ab474
                        at /home/user/work/rust/src/libsyntax/visit.rs:69
   9:     0x7f6600c1dba3 - syntax::visit::walk_struct_field::h2845befa07941a18
                        at /home/user/work/rust/src/libsyntax/visit.rs:611
  10:     0x7f6600c2028c - syntax::visit::Visitor::visit_struct_field::hb11317b31993e1d3
                        at /home/user/work/rust/src/libsyntax/visit.rs:87
  11:     0x7f6600c1bafb - syntax::visit::walk_struct_def::h460cba41f9913a70
                        at /home/user/work/rust/src/libsyntax/visit.rs:140
  12:     0x7f6600c202f7 - syntax::visit::Visitor::visit_variant_data::h34b9309f4a4656bf
                        at /home/user/work/rust/src/libsyntax/visit.rs:85
  13:     0x7f6600c2c1af - syntax::visit::walk_item::h952481656fd0fe0d
                        at /home/user/work/rust/src/libsyntax/visit.rs:286
  14:     0x7f6600c1f1ec - syntax::visit::Visitor::visit_item::h82930e5e5e342650
                        at /home/user/work/rust/src/libsyntax/visit.rs:61
  15:     0x7f6600cdb309 - <syntax_ext::deriving::custom::CustomDerive as syntax::ext::base::MultiItemModifier>::expand::hb85be6dadc698836
                        at /home/user/work/rust/src/libsyntax_ext/deriving/custom.rs:71
  16:     0x7f6600cfbf81 - syntax_ext::deriving::expand_derive::h11ea136a17126e4e
                        at /home/user/work/rust/src/libsyntax_ext/deriving/mod.rs:245
  17:     0x7f6600d0452f - core::ops::Fn::call::ha1fae1f0ef1c46d2
  18:     0x7f6600bba35c - <F as syntax::ext::base::MultiItemModifier>::expand::h32615659f51c84df
                        at /home/user/work/rust/src/libsyntax/ext/base.rs:135
  19:     0x7f65fa490a17 - syntax::ext::expand::MacroExpander::expand_attr_invoc::h41e5a9a709f86086
                        at /home/user/work/rust/src/libsyntax/ext/expand.rs:356
  20:     0x7f65fa49030b - syntax::ext::expand::MacroExpander::expand_invoc::hfd12226f9b1c5db7
                        at /home/user/work/rust/src/libsyntax/ext/expand.rs:332
  21:     0x7f65fa48ecc3 - syntax::ext::expand::MacroExpander::expand::h12c7b11a42c50ca2
                        at /home/user/work/rust/src/libsyntax/ext/expand.rs:269
  22:     0x7f65fa48dcd6 - syntax::ext::expand::MacroExpander::expand_crate::h0dc21b228744e473
                        at /home/user/work/rust/src/libsyntax/ext/expand.rs:208
  23:     0x7f6604991a0c - rustc_driver::driver::phase_2_configure_and_expand::{{closure}}::h9b9637cdecef8735
                        at /home/user/work/rust/src/librustc_driver/driver.rs:675
  24:     0x7f66046f068d - rustc::util::common::time::h18a389421cc20671
                        at /home/user/work/rust/src/librustc/util/common.rs:48
  25:     0x7f660498cd7e - rustc_driver::driver::phase_2_configure_and_expand::hbdde9dd6f937d0ab
                        at /home/user/work/rust/src/librustc_driver/driver.rs:638
  26:     0x7f660498673a - rustc_driver::driver::compile_input::h00c4724689831631
                        at /home/user/work/rust/src/librustc_driver/driver.rs:112
  27:     0x7f66049b2905 - rustc_driver::run_compiler::hc8108b737246cece
                        at /home/user/work/rust/src/librustc_driver/lib.rs:221
  28:     0x7f66049beda9 - rustc_driver::main::{{closure}}::hb94620e8836fbcdf
                        at /home/user/work/rust/src/librustc_driver/lib.rs:1118
  29:     0x7f66049b12ce - rustc_driver::run::{{closure}}::h1ecd8537d8480e64
                        at /home/user/work/rust/src/librustc_driver/lib.rs:137
  30:     0x7f66049bea82 - rustc_driver::monitor::{{closure}}::hbf80a57be51c8894
                        at /home/user/work/rust/src/librustc_driver/lib.rs:1052
  31:     0x7f6604941927 - <std::panic::AssertUnwindSafe<F> as core::ops::FnOnce<()>>::call_once::hd02e3f480f0a6eae
                        at /home/user/work/rust/src/libstd/panic.rs:296
  32:     0x7f66046193ca - std::panicking::try::do_call::h7674ae3dbd396508
                        at /home/user/work/rust/src/libstd/panicking.rs:460
  33:     0x7f6603fd2cb7 - __rust_try
  34:     0x7f6603fd2b37 - __rust_maybe_catch_panic
                        at /home/user/work/rust/src/libpanic_unwind/lib.rs:98
  35:     0x7f660461907f - std::panicking::try::h92a12de5d841affe
                        at /home/user/work/rust/src/libstd/panicking.rs:436
  36:     0x7f660461828a - std::panic::catch_unwind::hd118b8210d00de33
                        at /home/user/work/rust/src/libstd/panic.rs:361
  37:     0x7f6604618c93 - std::thread::Builder::spawn::{{closure}}::h64871368bcadb209
                        at /home/user/work/rust/src/libstd/thread/mod.rs:357
  38:     0x7f66046ac2ab - <F as alloc::boxed::FnBox<A>>::call_box::h24b488af099ea696
                        at /home/user/work/rust/src/liballoc/boxed.rs:605
  39:     0x7f6603ee82b9 - <Box<alloc::boxed::FnBox<A, Output$u3d$R$GT$$u20$$u2b$$u20$$u27$a$GT$$u20$as$u20$core..ops..FnOnce$LT$A$GT$$GT$::call_once::hf18c24e265f2b0c0
                        at /home/user/work/rust/src/liballoc/boxed.rs:615
  40:     0x7f6603f83c44 - std::sys_common::thread::start_thread::h589b492354cb4567
                        at /home/user/work/rust/src/libstd/sys_common/thread.rs:21
  41:     0x7f6603fba49c - std::sys::imp::thread::Thread::new::thread_start::h1351221081b4f008
                        at /home/user/work/rust/src/libstd/sys/unix/thread.rs:84
  42:     0x7f65f91293a3 - <unknown>
  43:     0x7f6603bcbbdc - clone
  44:                0x0 - <unknown>

@jseyfried
Copy link
Contributor

@keeperofdakeys Yeah, adding an empty fn visit_mac to the Visitor impl for MarkAttrs should be sufficient.

@keeperofdakeys
Copy link
Contributor

keeperofdakeys commented Dec 31, 2016

If you print the input to the derive function in the above example, you get this:

struct S {
    x: int!(),
}

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

bors added a commit that referenced this issue Dec 31, 2016
…yfried

Fix panic when using a macros 1.1 custom derive on a struct containing a macro invocation

Fixes #38706

r? @jseyfried
@jseyfried
Copy link
Contributor

jseyfried commented Jan 2, 2017

@keeperofdakeys (cc @nrc)

I can't help but wonder if it would be better to expand the int! macro before the derives.

Not expanding first can be strictly more powerful -- we can support something like

#[proc_macro_derive(A)]
fn derive(input: TokenStream) -> TokenStream {
    let input = input.expand_macros();

    // --- OR ---

    let input = match input.try_expand_macros() {
        Ok(input) => input,
        Err(err) => return MacroContext::pending(err);
    };
}

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 forcing proc_macro_derives not to depend on this by expanding the underlying item first might be a good idea.

Note that we currently "expand" cfg and cfg_attr before before proc_macro_derives.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
Projects
None yet
Development

No branches or pull requests

4 participants