Hi,
I've stumbled upon an error when I've tried to add conditional compilation to my quick_error defined Error enum. Here's an example:

quick_error! {
    #[derive(Debug)]
    pub enum Error {
        Io(err: std::io::Error) {
            cause(err)
            from()
            display("I/O error: {}", err)
        }
        #[cfg(feature="ssh2")]
        Ssh(err: ssh2::Error) {
            cause(err)
            from()
            display("SSH error: {}", err)
        }
        Net(err: std::net::AddrParseError) {
            cause(err)
            from()
            display("Network error: {}", err)
        }
        Zmq(err: zmq::Error) {
            cause(err)
            from()
            display("ZMQ error: {}", err)
        }
        Other(desc: String) {
            description(desc)
            from(desc: &str) -> (String::from(desc))
            from(err: Box<dyn std::error::Error>) -> (String::from(err.description()))
        }
    }
}

If I remove the from() from Ssh variant, then it compiles correctly. When I'm expanding the macro, I can see the #[cfg(feature="ssh2")] everywhere except for the

impl From<ssh2::Error> for Error {
    fn from(err: ssh2::Error) -> Error {
        Error::Ssh(err)
    }
}

New to rust and not sure how to proceed with this.

Running in a docker instance with rust:1.43.1.

Cargo.toml

[package]
name = "test-quick-error"
version = "0.1.0"
license = "MIT"
edition = "2018"

[dependencies]
quick-error = "1.2.3"

src/lib.rs

//! Library to test quick-error

#[macro_use]
extern crate quick_error;

quick_error! {
  /// Error return type.
  #[derive(Debug)]
  pub enum Error {
      /// HTTP client creation failed
      HttpClientError {
          description("HTTP Client creation failed")
      }

      /// Failed to parse final URL.
      UrlError {
          description("Failed to parse final URL")
      }

      /// Failed to make the outgoing request.
      RequestError {
          description("Failed to make the outgoing request")
      }

      /// Failed to perform IO operation
      IoError(std::io::Error) {
          description("Failed to make the outgoing request due to IO error")
      }

      /// Invalid parameter value
      InvalidValue {
          description("Invalid parameter value")
      }
  }
}

Error Message

$cargo build
   Compiling test-quick-error v0.1.0 (/usr/src/myapp)
error: no rules expected the token `=>`
  --> src/lib.rs:7:1
   |
7  | / quick_error! {
8  | |   /// Error return type.
9  | |   #[derive(Debug)]
10 | |   pub enum Error {
...  |
35 | |   }
36 | | }
   | |_^ no rules expected this token in macro call
   |
   = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to previous error

error: could not compile `test-quick-error`.

To learn more, run the command again with --verbose.
make: *** [Makefile:2: debug] Error 101

Observation: The main pain point of enums is the repetitiveness of match-statements. Which are scattered around at different locations. This is good for adding and removing a new trait implementation (which is a local change of code). But it is not good for adding and removing enum-variants. Quick-error does code transformations to invert this for a specific set of traits.

Here is the (possibly crazy) idea: What about a code transformation that is generic in terms of the traits, too - like this example

IN

enum_transform!(
  pub enum Foo {
    X => {
      #[define] Bar::baz(/* optional arguments*/) -> { Ok(()) }
    },
    Y => {
      #[define] Bar::baz(/* optional arguments*/) -> { Err(()) }
    }
  }

  impl Bar for Foo {
       fn baz(&self, /* .. */) -> Result<(), ()> {
           // ...
           match *self
           #[insert] { Bar::baz(/* optional arguments*/) }
           // ...
       }
  }
)

OUT

pub enum Foo {
  X,
  Y
}

impl Bar for Foo {
  fn baz(&self, /* .. */) -> Result<(), ()>
    // ...
    match *self {
      X => { Ok(()) };
      Y => { Err(()) };
    }
    // ...
  }
}

If we had such a generic enum_transform macro, then
(a) quick_error could be rewritten in terms of enum_transform AND
(b) quick_error could itself could allow generic substitutions like this

EDIT:

• Minor corrections

In https://github.com/gkoz/gir/blob/master/src/config.rs we use this enum for error of configuration processing:

#[derive(Debug)]
pub enum Error {
    CommandLine(DocoptError),
    Io(IoError, PathBuf),
    Toml(String, PathBuf),
    Options(String, PathBuf),
}

Last 3 errors here also contains file name.

Currently for error conversion we use tuple

try!(File::open(&filename)
     .and_then(|mut f| f.read_to_string(&mut input))
     .map_err(|e| (e, &filename)));

with From definition

impl<P: AsRef<OsStr>> From<(IoError, P)> for Error {
    fn from(e: (IoError, P)) -> Error {
        Error::Io(e.0, PathBuf::from(&e.1))
    }
}

This is the normal way to handle errors?
Currently seems no way to use this method in quick-error.
Can this functionality be added in quick-error?

It would be nice to implement display via direct access to the std::fmt::Formatter - as another option. This would allow additional logic inside the display logic without temporary buffers.

Use case: Complex enum-variant with Option<...> fields.

At first I was thinking about closures, but this would require to capture all fields explicitly - not so nice. Instead I suggest we provide it like display(f, me) -> { /* ... */ }.

Suggested Grammar (example)

display(me, f) -> {
    try!(write!(f, "{} Expected token {:?} but found {:?} at {:?}.",
        me.description(), expected, found.token(), found.position()));

    // additional logic

    Ok(())
}

Current Workaround - needs redundant allocation for temporary buffer

display(me) -> ("{buf}", buf={
    use std::fmt::Write;
    let mut f = String::new()
    write!(f, "{} Expected token {:?} but found {:?} at {:?}.",
        me.description(), expected, found.token(), found.position()).unwrap();

    // additional logic

    f
}

EDIT:

• changed argument order in display.

I tried to code an error for quick-xml error (http://tafia.github.io/quick-xml/quick_xml/error/type.ResultPos.html):

quick_error! {
    #[derive(Debug)]
    pub enum DictError {
        XmlError { err: quick_xml::error::Error, pos: usize } {
            from(terr: (quick_xml::error::Error, usize)) -> {
                err: terr.0,
                pos: terr.1,
            }
        }
    }
}

but I got following error:

<quick_error macros>:99:26: 99:42 error: no rules expected the token `STRUCT`
<quick_error macros>:99 $ ( # [ $ bmeta ] ) * => $ bitem : STRUCT [ $ ( $ qvar : $ qtyp ) , * ] ]

I can't realize what's wrong.

This issue was automatically generated. Feel free to close without ceremony if
you do not agree with re-licensing or if it is not possible for other reasons.
Respond to @cmr with any questions or concerns, or pop over to
#rust-offtopic on IRC to discuss.

You're receiving this because someone (perhaps the project maintainer)
published a crates.io package with the license as "MIT" xor "Apache-2.0" and
the repository field pointing here.

TL;DR the Rust ecosystem is largely Apache-2.0. Being available under that
license is good for interoperation. The MIT license as an add-on can be nice
for GPLv2 projects to use your code.

Why?

The MIT license requires reproducing countless copies of the same copyright
header with different names in the copyright field, for every MIT library in
use. The Apache license does not have this drawback. However, this is not the
primary motivation for me creating these issues. The Apache license also has
protections from patent trolls and an explicit contribution licensing clause.
However, the Apache license is incompatible with GPLv2. This is why Rust is
dual-licensed as MIT/Apache (the "primary" license being Apache, MIT only for
GPLv2 compat), and doing so would be wise for this project. This also makes
this crate suitable for inclusion and unrestricted sharing in the Rust
standard distribution and other projects using dual MIT/Apache, such as my
personal ulterior motive, the Robigalia project.

Some ask, "Does this really apply to binary redistributions? Does MIT really
require reproducing the whole thing?" I'm not a lawyer, and I can't give legal
advice, but some Google Android apps include open source attributions using
this interpretation. Others also agree with
it.
But, again, the copyright notice redistribution is not the primary motivation
for the dual-licensing. It's stronger protections to licensees and better
interoperation with the wider Rust ecosystem.

How?

To do this, get explicit approval from each contributor of copyrightable work
(as not all contributions qualify for copyright, due to not being a "creative
work", e.g. a typo fix) and then add the following to your README:

## License

Licensed under either of

 * Apache License, Version 2.0, ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
 * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)

at your option.

### Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any
additional terms or conditions.

and in your license headers, if you have them, use the following boilerplate
(based on that used in Rust):

// Copyright 2016 quick-error Developers
//
// Licensed under the Apache License, Version 2.0, <LICENSE-APACHE or
// http://apache.org/licenses/LICENSE-2.0> or the MIT license <LICENSE-MIT or
// http://opensource.org/licenses/MIT>, at your option. This file may not be
// copied, modified, or distributed except according to those terms.

It's commonly asked whether license headers are required. I'm not comfortable
making an official recommendation either way, but the Apache license
recommends it in their appendix on how to use the license.

Be sure to add the relevant LICENSE-{MIT,APACHE} files. You can copy these
from the Rust repo for a plain-text
version.

And don't forget to update the license metadata in your Cargo.toml to:

license = "MIT OR Apache-2.0"

I'll be going through projects which agree to be relicensed and have approval
by the necessary contributors and doing this changes, so feel free to leave
the heavy lifting to me!

Contributor checkoff

To agree to relicensing, comment with :

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

Or, if you're a contributor, you can check the box in this repo next to your
name. My scripts will pick this exact phrase up and check your checkbox, but
I'll come through and manually review this issue later as well.

• @tailhook
• @colin-kiegel

It could be convenient for users to use this library

It seems like quick_error has fallen behind on modern rust idioms. Are you planning on updating this crate further? Maybe it would be prudent to suggest a more modern and maintained alternative like thiserror in the readme if not. Otherwise, issues like #42 and #48 are blockers for some users, myself included.

All the traits you use are in core (except Error), so it should be easy.

I just discovered that this isn't possible:

quick_error! {
    pub enum MyFancyError<E> {
        Foo(e: E) { }
    }
}

Which is a shame, because this would be very useful.

Sometimes we need to wrap our error into a ExternError:

impl From<MyError> for ExternError{
    fn from(err: MyError) -> Self {
        ExternError::Other(Box::new(err))
    }
}

But this can't be implemented for Context on our side, making the usage of ? operator on a Context isn't possible.
It would be awesome to have something like this:

quick_error! {
    #[derive(Debug)]
    pub enum MyError{
        SomeError(name: String, err: AError) {
            display(...)
            context(text: String, err: AError) -> (text, err)
        }
        ....
    },
    from(err: MyError) -> { // A block, will be called in from<myerror> and from<context>
        ExternError::Other(Box::new(err))
    }
}
// generates following code:
....

impl From<MyError> for ExternError {
    fn from(err: MyError) -> Self {
        ExternError::Other(Box::new(err))
    }
}
impl<'a> From<$crate::Context<String, EscapeError>> for ExternError {
    fn from($crate::Context(name, err): $crate::Context<String, AError>) -> ExternError {
        ExternError::from(MyError::SomeError(name, err));
    }
}

quick-error is by far my preferred error handling solution in Rust. I like it more than failure or error-chain. However, it is a shame that its functionality is limited due to limitations of the macro_rules syntax. For example: lack of generics support (issue #20). Also: poor error messages.

I believe these issues could be resolved if quick_error was implemented as a procedural macro, which is now stable as of Rust 1.30. This would greatly improve the usefulness of the crate, at least for projects that don't mind the 1.30 minimum Rust version requirement.

It could be released as a new semver-incompatible version to avoid bumping the minimum Rust requirement of old code that depends on this crate to 1.30 due to automatic upgrade.

Are you planning to add support for plain structs, rather than just enums?

Currently, error-chain uses quick-error by just copying the file to src/quick_error.rs, with #30 applied and removal of the Error implementation. That's not ideal since we have to copy the file and make the changes instead of just updating Cargo.toml. Solutions I see:

• Don't change anything.
• Use macro_reexport: nightly only, not in path for stabilisation.
• Add quick-error as a git sub-module and make a symbolic link. $crate could work if I reexport the few items you define in the crate... except that I also define a ResultExt ^^

And there is still the issue with Error.

Any thought about it?

When generating docs (cargo doc) documentation is included with ///

Example:

/// Document outside quick_error
pub fn foo() {}

quick_error! {
    /// Document the overall error type
    #[derive(Debug)]
    pub enum ErrorType {
        /// Document first variant
        FirstVariant(e: i32) {
            from()
        }
        /// Document second variant
        SecondVariant {}
    }
}

expands to (can be seen with cargo rustc -- -Z unstable-options --pretty=expanded)

/// Document outside quick_error
pub fn foo() {}

#[doc = "/// Document the overall error type"]
pub enum ErrorType {

    #[doc = "/// Document first variant"]
    FirstVariant(i32),

    #[doc = "/// Document second variant"]
    SecondVariant,
}

which leads to the generated html docs looking like

Functions
foo Document outside quick_error
Enums
ErrorType /// Document the overall error type
Variants
FirstVariant /// Document first variant
SecondVariant /// Document second variant

I think we are ready to release quick-error 1.0.0. The crate is stable enough. There are few issues on github but they are for features, not bugs.

There are already 20 crates that depend on quick-error, so I believe breaking them is a bad idea anyway.

@colin-kiegel, what do you think?

Currently I have code that looks like this:

quick_error! {
    #[derive(Debug)]
    pub enum ServerError {
        Io(error: io::Error) {
            display("{}", error)
            description(error.description())
            cause(error)
            from()
        }
        JsonDecode(error: json::DecoderError) {
            display("{}", error)
            description(error.description())
            cause(error)
            from()
        }
        JsonEncode(error: json::EncoderError) {
            display("{}", error)
            description(error.description())
            cause(error)
            from()
        }
        ConfigError(error: config::Error) {
            display("{}", error)
            description(error.description())
            cause(error)
            from()
        }
    }
}

I see a few options to remove that boilerplate:

• Make from() set those defaults automatically for simple wrappers.
• Ability to override defaults on a per-enum basis, not only per-variant. No idea how syntax could look like.

Some people prefer

enum {
    A,
    B,
    C,
}

quick_error should support that style in the macro.

compile error: self is not available in a static method. Maybe a self argument is missing? [E0424]

I would like to reuse the error description in the Display::fmt function on some occasions. It would be nice to do this by delegation to self.description(). There might be addional usecases for &self access.

quick_error! {
    #[derive(Debug)]
    pub enum LoaderError {
        ArrayTemplateNotFound(name: String) {
            description("Template not found")
            display("{}: {:?}", self.description(), name)
        }
    }
}

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

This is a great library. 👍

One thing I am missing is struct-like variants:

quick_error! {
    #[derive(Debug)]
    pub enum IoWrapper {
        IoAt(place: &'static str, err: io::Error) {}
    }
}

let err = IoWrapper::IoAt {
    place: unimplemented!(),
    err: unimplemented!()
}  // compile error: `IoWrapper::IoAt` does not name a structure 

Support for struct-like variants would be great AND it would help migrating some existing error definitions to quick-error.

I just checked: std-lib uses struct-like variants for some error enums too:

• std::str::Utf8Error
• std::sync::PoisonError
• std::string::FromUtf8Error

So there seem to be use cases to use both kind of variants. Is it generally possible to implement at all? If so, the syntax could be curly-braces IoAt{place: ..} {} instead of round-braces IoAt(place: ..) {}.

This would be useful mainly for adding doc comments

quick_error! {
    /// We can put comments here
    pub enum MyError {
        /// And we can put comments here
        MyVariant {
            /// But we can't put em ere
            my_variant_member: MyType,
        } {}
    }
}

    /// A page management error.
    enum Error {
        /// No clusters left in the freelist.
        ///
        /// This is the equivalent to OOM, but with disk space.
        OutOfClusters {
            description("Out of free clusters.")
        }
        /// A page checksum did not match.
        ///
        /// The checksum of the data and the checksum stored in the page pointer did not match.
        ///
        /// This indicates some form of data corruption in the sector storing the page.
        PageChecksumMismatch {
            /// The page with the mismatching checksum.
            page: page::Pointer,
            /// The actual checksum of the page.
            found: u32,
        } {
            display("Mismatching checksums in {} - expected {:x}, found {:x}.",
                    page, page.checksum, found)
            description("Mismatching checksum in page.")
        }
    }

gives error

error: expected ident, found #
  --> /home/andy/code/tfs/src/io/alloc.rs:22:13
   |
22 |             /// The page with the mismatching checksum.
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Example:

quick_error! {
    /// An awesome error.
    #[derive(Debug)]
    pub enum IoWrapper {
        /// A cool variant
        Io(err: io::Error) {
            from()
        }
    }
}

Putting doc comments on the variants in the quick_error macro causes rustc to emit warnings despite the comments actually appearing in rustdoc. https://docs.rs/gluon/0.5.0/gluon/enum.Error.html

quick_error! {
    #[derive(Debug, PartialEq)]
    pub enum Error {
        /// Some comment
        Error(err: String) {
            display("{}", err)
        }
    }
}

I guess this is because the doc comments/attributes gets attached to something that rustdoc does not use in addition to some place which it does use. Would it be possible to supress the warnings in the macro itself or should it be supressed on the call-site?

This doesn't seem to work:

quick_error! {
    pub(crate) enum FooError {
        ...
    }
}

Would be great to have support for visibility modifiers 🙂

Currently I take great of not degenerating any error information. Thus I might end up with hierarchies of errors linked up by their cause().

However, currently displaying the error is manually implemented, and it appears the causes are not printed.

Do you see a way to have the causes followed and printed automatically ?

Is there any way of getting file+line number into the error message?

It would be nice if something like this was possible:

quick_error! {
    #[derive(Debug)]
    pub enum MagicHeaderParseError {
        Io(error: IoError) {
            description(error.description())
            display("{}", error.display())
            cause(error.cause())
            from(error: IoError) -> (error)
        }
    }
}

Right now this doesn't work, as description(...) only accepts string literals, and cause cannot take Options.

<quick_error macros>:192:1: 197:60 error: recursion limit reached while expanding the macro `quick_error
<quick_error macros>:192 quick_error ! (
<quick_error macros>:193 ENUM_DEFINITION [ $ ( $ def ) * ] body [
<quick_error macros>:194 $ (
<quick_error macros>:195 $ ( # [ $ imeta ] ) * => $ iitem ( $ ( ( $ ( $ ttyp ) , + ) ) * ) {
<quick_error macros>:196 $ ( { $ ( $ svar : $ styp ) , * } ) * } ) * $ ( # [ $ qmeta ] ) * => $ qitem (
<quick_error macros>:197 ( $ ( $ qtyp ) , * ) ) {  } ] queue [ $ ( $ queue ) * ] ) ; } ; (
Could not compile `openid-connect`.

i have an error type with 17 possible error types. is that too many? it works if i delete one. doesn't seem to matter which one i get rid of.