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

Panic when compiling a describe block with a string instead of identifier #88

Open
provegard opened this issue Dec 27, 2017 · 6 comments

Comments

@provegard
Copy link

I have the following src/main.rs:

#![feature(plugin)]
#![cfg_attr(test, plugin(stainless))]

describe! stainless {
    describe! "add" {
        it "works" {}
    }
}

When I run cargo test, I get:

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

note: rustc 1.24.0-nightly (4a7c072fa 2017-12-25) running on x86_64-pc-windows-msvc

note: run with `RUST_BACKTRACE=1` for a backtrace

thread 'rustc' panicked at 'Diagnostic { level: Fatal, message: [("Failed to parse the name of the describe block, got err: Diagnostic { level: Fatal, message: [(\"expected identifier, found `\\\"add\\\"`\", NoStyle)], code: None, span: MultiSpan { primary_spans: [Span { lo: BytePos(95), hi: BytePos(100), ctxt: #0 }], span_labels: [] }, children: [], suggestions: [] }", NoStyle)], code: None, span: MultiSpan { primary_spans: [Span { lo: BytePos(95), hi: BytePos(100), ctxt: #0 }], span_labels: [] }, children: [], suggestions: [] }', C:\Users\Per\.cargo\registry\src\github.com-1ecc6299db9ec823\stainless-0.1.12\src\parse.rs:109:24
stack backtrace:
   0: std::sync::mpsc::sync::Queue::dequeue
   1: std::panicking::Location::column
   2: std::panicking::Location::column
   3: std::panicking::rust_panic_with_hook
   4: std::panicking::begin_panic_fmt
   5: std::panicking::begin_panic_fmt
   6: stainless::parse::{{impl}}::parse
             at C:\Users\Per\.cargo\registry\src\github.com-1ecc6299db9ec823\stainless-0.1.12\src\parse.rs:109
   7: stainless::parse::{{impl}}::parse
             at C:\Users\Per\.cargo\registry\src\github.com-1ecc6299db9ec823\stainless-0.1.12\src\parse.rs:180
   8: stainless::describe::describe
             at C:\Users\Per\.cargo\registry\src\github.com-1ecc6299db9ec823\stainless-0.1.12\src\describe.rs:66
   9: core::ops::function::Fn::call<fn(mut syntax::ext::base::ExtCtxt*, syntax_pos::span_encoding::Span, syntax_pos::symbol::Ident, alloc::vec::Vec<syntax::tokenstream::TokenTree>) -> alloc::boxed::Box<MacResult>,(mut syntax::ext::base::ExtCtxt*, syntax_pos::span_encoding::Span, syntax_pos::symbol::Ident, alloc::vec::Vec<syntax::tokenstream::TokenTree>)>
             at C:\projects\rust\src\libcore\ops\function.rs:73
  10: syntax::ext::base::{{impl}}::expand<fn(mut syntax::ext::base::ExtCtxt*, syntax_pos::span_encoding::Span, syntax_pos::symbol::Ident, alloc::vec::Vec<syntax::tokenstream::TokenTree>) -> alloc::boxed::Box<MacResult>>
             at C:\projects\rust\src\libsyntax\ext\base.rs:261
  11: syntax::ext::expand::MacroExpander::expand_crate
  12: syntax::ext::expand::MacroExpander::expand_crate
  13: syntax::ext::expand::MacroExpander::expand_crate
  14: rustc_driver::driver::count_nodes
  15: rustc_driver::driver::count_nodes
  16: rustc_driver::driver::compile_input
  17: rustc_driver::run_compiler
  18: <rustc_driver::pretty::UserIdentifiedItem as core::fmt::Debug>::fmt
  19: _rust_maybe_catch_panic
  20: rustc_driver::profile::dump
  21: std::sync::mpsc::sync::Queue::dequeue
  22: std::sys::windows::thread::Thread::new
  23: BaseThreadInitThunk

Note that this only happens for a nested describe!. If I change the code to describe! "stainless" {, I get a proper error message:

error: expected open delimiter
 --> src\main.rs:4:11
  |
4 | describe! "stainless" {
  |           ^^^^^^^^^^^

@ujh
Copy link
Collaborator

ujh commented Dec 27, 2017 via email

@provegard
Copy link
Author

Nope, same result. I'm not looking for a way to use strings for my describes though.

@provegard
Copy link
Author

The error message printed for an incorrect top-level describe is fine. It should be the same for nested describes. :-)

@ujh
Copy link
Collaborator

ujh commented Dec 28, 2017 via email

@provegard
Copy link
Author

Sure! Where does that leave this issue?

@ujh
Copy link
Collaborator

ujh commented Dec 28, 2017 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants