proc-macro panics when tokenizing `..=` in attributes

[alexcrichton]

Given lib.rs:

#![crate_name = "foo"]
#![crate_type = "proc-macro"]
#![feature(proc_macro)]

extern crate proc_macro;

use proc_macro::*;

#[proc_macro_attribute]
pub fn foo(_a: TokenStream, b: TokenStream) -> TokenStream {
    recreate(b)
}

fn recreate(a: TokenStream) -> TokenStream {
    a.into_iter().map(|t| {
        match t.kind {
            TokenNode::Group(d, c) => TokenNode::Group(d, recreate(c)),
            other => other,
        }
    }).collect()
}

and main.rs

#![feature(proc_macro)]

extern crate foo;

use foo::foo;

#[foo]
fn main() {
    let a = 1..=3;
}

you can compile as:

$ rustc +nightly lib.rs
$ rustc +nightly main.rs -L .
thread 'rustc' panicked at 'internal error: entered unreachable code', libproc_macro/lib.rs:688:22
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:380
   3: std::panicking::default_hook
             at libstd/panicking.rs:396
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:576
   5: std::panicking::begin_panic
   6: <proc_macro::TokenTreeIter as core::iter::iterator::Iterator>::next
   7: <core::iter::Map<I, F> as core::iter::iterator::Iterator>::next
   8: <proc_macro::TokenStream as core::iter::traits::FromIterator<T>>::from_iter
   9: core::iter::iterator::Iterator::collect
  10: foo::recreate
  11: foo::recreate::{{closure}}
  12: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &'a mut F>::call_once
  13: <core::option::Option<T>>::map
  14: <core::iter::Map<I, F> as core::iter::iterator::Iterator>::next
  15: <proc_macro::TokenStream as core::iter::traits::FromIterator<T>>::from_iter
  16: core::iter::iterator::Iterator::collect
  17: foo::recreate
  18: foo::foo
  19: std::panicking::try::do_call
  20: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
  21: <std::thread::local::LocalKey<T>>::with
  22: <syntax_ext::proc_macro_impl::AttrProcMacro as syntax::ext::base::AttrProcMacro>::expand
  23: syntax::ext::expand::MacroExpander::expand_invoc
  24: syntax::ext::expand::MacroExpander::expand
  25: syntax::ext::expand::MacroExpander::expand_crate
  26: rustc_driver::driver::phase_2_configure_and_expand_inner::{{closure}}
  27: rustc::util::common::time
  28: rustc_driver::driver::phase_2_configure_and_expand
  29: rustc_driver::driver::compile_input
  30: rustc_driver::run_compiler
error: custom attribute panicked
 --> src/main.rs:7:1
  |
7 | #[foo]
  | ^^^^^^
  |
  = help: message: internal error: entered unreachable code

[dtolnay]

Strange!

rust/src/libproc_macro/lib.rs

Line 688 in 6741e41

DotEq => unreachable!(),

[varkor]

Presumably this should just be: DotEq => joint!('.', Eq). Looks like it could just be an oversight in e64efc9#diff-9ea37887c69f218bed1798983de82b79, especially considering this comment.

[dtolnay]

I believe so.

[durka]

If someone were to try to write a test for this, where would it go? Does it need to be a run-make test?

[varkor]

It seems so specific and such a clear oversight that I feel a test shouldn't really be necessary: it's not something that's going to regress, because there's nothing to set it apart from any of the other cases once it's fixed.