ICE: unrecognized builtin nonterminal t_ty

[GuillaumeGomez]

Hi,

Here's the error:

Compiling rgtk v0.0.1 (file:///home/imperio/rust/d/rgtk)
error: internal compiler error: unrecognized builtin nonterminal t_ty
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: http://doc.rust-lang.org/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'Box<Any>', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libsyntax/diagnostic.rs:185

stack backtrace:
   1:     0x7ffba5f68830 - sys::backtrace::write::hd2229fdc498b155b6St
   2:     0x7ffba5f8a210 - failure::on_fail::h52544b4c202b33caN6z
   3:     0x7ffba5ef8fe0 - rt::unwind::begin_unwind_inner::he6cc32870f98504cGLz
   4:     0x7ffba0b708b0 - rt::unwind::begin_unwind::h5028088592122257597
   5:     0x7ffba0b71150 - diagnostic::Handler::bug::h9d16902109ea5c7d0uF
   6:     0x7ffba0dd23b0 - ext::tt::macro_rules::is_in_follow::h3ff26d010a5f665bTcj
   7:     0x7ffba0dd1510 - ext::tt::macro_rules::check_matcher::h12446878346505120654
   8:     0x7ffba0cb68a0 - ext::tt::macro_rules::compile::h584824075a9259a6QZi
   9:     0x7ffba0cb6500 - ext::base::ExtCtxt<'a>::insert_macro::h1a73f08ebd1871c8ek7
  10:     0x7ffba0d23860 - ext::expand::expand_item_mac::h42d16756784e72c2BWd
  11:     0x7ffba0d102b0 - ext::expand::expand_annotatable::hd2a4239b0ca13e44xre
  12:     0x7ffba0d0da50 - ext::expand::expand_item::haa623afbddd493caRQd
  13:     0x7ffba0d1d7e0 - ext::expand::MacroExpander<'a, 'b>.Folder::fold_item::hdc693973fb705718yJe
  14:     0x7ffba0d1d780 - fold::noop_fold_mod::unboxed_closure.55755
  15:     0x7ffba0d1d710 - option::Option<T>::map::h844566629590064802
  16:     0x7ffba0d1d190 - vec::Vec<T>.FromIterator<T>::from_iter::h11293294185601853047
  17:     0x7ffba0d1a480 - fold::noop_fold_mod::h18103556734474978201
  18:     0x7ffba0d15db0 - ext::expand::expand_item_underscore::h42fa244589d0ab8apUd
  19:     0x7ffba0d795a0 - fold::noop_fold_item_simple::h6341453819017668533
  20:     0x7ffba0d79040 - ptr::P<T>::map::h4634736471424973638
  21:     0x7ffba0d102b0 - ext::expand::expand_annotatable::hd2a4239b0ca13e44xre
  22:     0x7ffba0d0da50 - ext::expand::expand_item::haa623afbddd493caRQd
  23:     0x7ffba0d1d7e0 - ext::expand::MacroExpander<'a, 'b>.Folder::fold_item::hdc693973fb705718yJe
  24:     0x7ffba0d1d780 - fold::noop_fold_mod::unboxed_closure.55755
  25:     0x7ffba0d1d710 - option::Option<T>::map::h844566629590064802
  26:     0x7ffba0d1d190 - vec::Vec<T>.FromIterator<T>::from_iter::h11293294185601853047
  27:     0x7ffba0d1a480 - fold::noop_fold_mod::h18103556734474978201
  28:     0x7ffba0d15db0 - ext::expand::expand_item_underscore::h42fa244589d0ab8apUd
  29:     0x7ffba0d795a0 - fold::noop_fold_item_simple::h6341453819017668533
  30:     0x7ffba0d79040 - ptr::P<T>::map::h4634736471424973638
  31:     0x7ffba0d102b0 - ext::expand::expand_annotatable::hd2a4239b0ca13e44xre
  32:     0x7ffba0d0da50 - ext::expand::expand_item::haa623afbddd493caRQd
  33:     0x7ffba0d1d7e0 - ext::expand::MacroExpander<'a, 'b>.Folder::fold_item::hdc693973fb705718yJe
  34:     0x7ffba0d1d780 - fold::noop_fold_mod::unboxed_closure.55755
  35:     0x7ffba0d1d710 - option::Option<T>::map::h844566629590064802
  36:     0x7ffba0d1d190 - vec::Vec<T>.FromIterator<T>::from_iter::h11293294185601853047
  37:     0x7ffba0d1a480 - fold::noop_fold_mod::h18103556734474978201
  38:     0x7ffba0d15db0 - ext::expand::expand_item_underscore::h42fa244589d0ab8apUd
  39:     0x7ffba0d795a0 - fold::noop_fold_item_simple::h6341453819017668533
  40:     0x7ffba0d79040 - ptr::P<T>::map::h4634736471424973638
  41:     0x7ffba0d102b0 - ext::expand::expand_annotatable::hd2a4239b0ca13e44xre
  42:     0x7ffba0d0da50 - ext::expand::expand_item::haa623afbddd493caRQd
  43:     0x7ffba0d1d7e0 - ext::expand::MacroExpander<'a, 'b>.Folder::fold_item::hdc693973fb705718yJe
  44:     0x7ffba0d818c0 - ext::expand::expand_crate::h7260acfae5bd0ea8pOe
  45:     0x7ffba64f1a90 - driver::phase_2_configure_and_expand::unboxed_closure.18555
  46:     0x7ffba64b34e0 - driver::phase_2_configure_and_expand::h169e6d47ee4a3664Rta
  47:     0x7ffba64a8ef0 - driver::compile_input::hb0db4842b7b65520Aba
  48:     0x7ffba656aa40 - run_compiler::h5a4f503c8f751442lac
  49:     0x7ffba65691b0 - thunk::F.Invoke<A, R>::invoke::h14750395715685073347
  50:     0x7ffba6568110 - rt::unwind::try::try_fn::h11237913591935978741
  51:     0x7ffba5ff1280 - rust_try_inner
  52:     0x7ffba5ff1270 - rust_try
  53:     0x7ffba65683c0 - thunk::F.Invoke<A, R>::invoke::h1317937348465981424
  54:     0x7ffba5f77eb0 - sys::thread::thread_start::h229ade6143a76a02TKw
  55:     0x7ffba038b0c0 - start_thread
  56:     0x7ffba5b99fd9 - __clone
  57:                0x0 - <unknown>

Could not compile `rgtk`.

Here's the rustc version:

rustc 1.0.0-nightly (ed530d7a3 2015-01-16 22:41:16 +0000)

And here is the code:

($signal:ident, $class:ident ( $($arg_name:ident : $arg_type:ty),* ) -> $ret_type:ty,
                    trampoline   ( $($t_arg_nm:ident : $t_arg_ty:ty),* ) -> $t_ret_ty:t_ty $t_blck:expr) => (

[jdm]

This is caused by the wildcard match is is_in_follow in macro_rules.rs. I would make that function return a Result type, and change the caller to deal with the Err case, since it has a span it can use for reporting.

[aochagavia]

I am testing a fix right now.

Btw, I have found an unrelated issue with the following code. It only produces an error when the macro is actually used. I would expect compilation to fail even if the macro is never used (as in some libraries that expose macros).

macro_rules! test { ($wrong:t_ty) => () }

fn main() {
     //test!("hello world"); only causes an error if uncommented
}

Should I open a new issue?

[jdm]

Yes, a new issue for the problem sounds good.

[emberian]

I'm really surprised this happens, the macro_rules parser is supposed to reject unrecognized fragment specifiers before follow checking gets hit, I thought.

[aochagavia]

@cmr The function that is supposed to reject the specifiers is here. However, it is clear that it doesn't work. It could be that my PR fixes the effects of this bug instead of fixing the real bug...

[apoelstra]

Here is a one-line example of this bug: macro_rules! something { ($tr:t,) => {} }. Interestingly, it only triggers if the comma is there.

[GuillaumeGomez]

@jdm: when you speak about returning an Err, are you talking about something like that:

pub fn parse_nt(p: &mut Parser, name: &str) -> Result<Nonterminal, Nonterminal> {

Seems weird no ? Or maybe I misunderstood something ?

[jdm]

I was only talking about the is_in_follow function, not parse_nt.