Error reporting of bad description definition
tailhook opened this issue · 4 comments
When description is defined in wrong way:
description("error decoding file name {:?}", path)
(i.e. this is clearly should be displayed, you can't format anything with description, and description has only one field)
The error is like the following:
<quick_error macros>:37:23: 37:34 error: no rules expected the token `ERROR_CHECK`
<quick_error macros>:37 ; $ ( quick_error ! ( ERROR_CHECK $ ( $ ifuncs ) * ) ; ) * } ; (
^~~~~~~~~~~
I. e. it's very misleading. Rust version is 1.3
I just stumbled upon it too, and I observed the following it makes a difference, whether the error occurs inside a foreign crate, or inside the quick-error crate which defines the macro. Take this example:
quick_error! {
#[derive(Debug)]
pub enum Wrapper {
Foo(err: Foo) {
__some_typo_in_description("Foo")
}
}
}
Inside crate quick-error it yields a nice and descriptive error:
src/lib.rs:735:17: 735:43 error: no rules expected the token `__some_typo_in_description`
src/lib.rs:735 __some_typo_in_description("Foo")
^~~~~~~~~~~~~~~~~~~~~~~~~~
Outside crate quick-error exactly the same error is presented quite differently and very obscure. In this case it even seems wrong, where the '^~~~' is pointing at.
<quick_error macros>:86:26: 86:41 error: no rules expected the token `TUPLE`
<quick_error macros>:86 $ ( # [ $ bmeta ] ) * => $ bitem : TUPLE [ $ ( $ qvar : $ qtyp ) , * ] ] queue
^~~~~~~~~~~~~~~
It is the same with your example - inside crate quick-error
src/lib.rs:735:60: 735:61 error: no rules expected the token `,`
src/lib.rs:735 description("error decoding file name {:?}", path)
^
Outside
<quick_error macros>:86:26: 86:41 error: no rules expected the token `TUPLE`
<quick_error macros>:86 $ ( # [ $ bmeta ] ) * => $ bitem : TUPLE [ $ ( $ qvar : $ qtyp ) , * ] ] queue
^~~~~~~~~~~~~~~
I would say the macro is good, but rust needs some improvement for presentation of these kinds of errors if the macro is used and defined in different crates.
I will file an issue, I think it is quite important. ... :-)
as of colin-kiegel's post this issue should be fixed
Great! Thanks for reporting.