arnavion/derive-error-chain

A Macros 1.1 implementation of https://crates.io/crates/error-chain

derive-error-chain's Issues

Support deriving on structs

Deriving on a struct should be identical to deriving on an enum with only one variant.

Brought up in rust-lang-deprecated/failure#66 (comment)

Undocumented dependencies

It is undocumented that using a given version of derive_error_chain requires the use of a specific version of error_chain.

For example, to use derive-error-chain = "=0.11.2", one also has to specify error-chain = "=0.11.0" in Cargo.toml. otherwise, one gets unexpected errors from inside the procedural macro (Exact errors depend on specific version combination).

This should either be documented, or otherwise include error-chain as an explicit dependency (since one doesn't even need to extern crate error_chain in one's crate root)

Add `const("some string literal with {parameters}")` as a shorthand for `display()`

As a workaround, one can use a closure instead of a function path:

#[derive(Debug, error_chain)]
pub enum ErrorKind {
	Msg(String),

	#[error_chain(custom, display = "http_status_display")]
	HttpStatus(u32),
}

fn http_status_display(f: &mut ::std::fmt::Formatter, e: &u32) -> ::std::fmt::Result {
	write!(f, "http request returned an unsuccessful status code: {}", e)
}

can be written as

#[derive(Debug, error_chain)]
pub enum ErrorKind {
	Msg(String),

	#[error_chain(custom)]
	#[error_chain(display = r#"(|f: &mut ::std::fmt::Formatter, e| write!(f, "http request returned an unsuccessful status code: {}", e))"#)]
	HttpStatus(u32),
}

Update example and tests for #[cfg] on variants

Need to check if #[cfg] is evaluated before proc macro is invoked. If yes, then don't need any code change.

Ref: rust-lang-deprecated/error-chain#55

Replace `error_chain!`

With macros 1.1 on stable, do you think your crate could replace the upstream error_chain?

Update pm2, syn, quote for nightly breakages

https://github.com/alexcrichton/proc-macro2/releases/tag/0.4.0
https://github.com/dtolnay/quote/releases/tag/0.6.0
https://github.com/dtolnay/syn/releases/tag/0.14.0

Documentation updates

• ErrorKind must derive Debug
• ErrorKind must be pub
• If using both error-chain and derive-error-chain, #[macro_use] extern crate error_chain; must come before #[macro_use] extern crate derive_error_chain;
• Doesn't need nightly compiler any more.
• Document attributes like serde - enum vs field attributes, a description for each attribute.

Don't require `ErrorKind` to be `pub`

• The ErrorKind must have pub visibility. error_chain! does this implicitly.

This rule exists because Error, Result and ResultExt are always emitted with pub, so the ErrorKind needs to be pub to avoid "private type is exposed publicly" errors.

Instead, those three should only be pub if the ErrorKind is pub.

Make Msg optional

rust-lang-deprecated/error-chain#200 shows there is demand.

Change display and description to receive all members instead of a tuple of the members

The initial reason was to be able to use .. to receive only the subset of members the function cares about, but this doesn't work if one or more of the members require type annotations for any reason.

Make Sync configurable

Probably via new enum attribute #[error_chain(sync = "true")]

rust-lang-deprecated/error-chain#110
rust-lang-deprecated/error-chain#121
rust-lang-deprecated/error-chain#134

This is blocked since error-chain needs to provide a way to do it first, since this crate uses the same traits as error-chain.

Support specifying custom `Error::cause`

error-chain doesn't support it, but it's a nice to have for custom errors like JSON { filename: String, error: ::serde_json::Error } that won't quite work as regular foreign links.

Ref: rust-lang-deprecated/error-chain#109

Port error-chain's tests

https://github.com/brson/error-chain/blob/master/tests/tests.rs

Update for error-chain v0.12.0

rust-lang-deprecated/error-chain@baee12b
rust-lang-deprecated/error-chain@fb9ea0e
rust-lang-deprecated/error-chain@92a54ba
rust-lang-deprecated/error-chain@1d7157c

Use upstream traits - Backtrace, ChainedError, ErrorChainIter, ResultExt, State

I recently added the ChainedError trait to error-chain. It would be cool if you could implement in with your crate, so that the two could be used together. Here is how it is implemented in the macro: https://github.com/brson/error-chain/blob/master/src/error_chain.rs#L71-L84.
I'll add your crate in my README ;)

Rename `#[derive(error_chain)]` to `#[derive(ErrorChain)]`

Per rust-lang/rust#38356 (comment) it is a compiler error to have a proc_macro_derive use its name for an attribute like this crate does (#[derive(error_chain)] and #[error_chain(...)]) since the latter is also the syntax for proc_macro_attribute macros.

#[derive(error_chain)] should be renamed to #[derive(ErrorChain)] and the attribute can continue to be #[error_chain(...)]. This is better than the other way around in that it's consistent with other proc macros, eg #[derive(Deserialize)] and #[serde(...)]

#[derive(error_chain)] could be kept around as well, so that code that doesn't use #[error_chain] can continue to use #[derive(error_chain)]. But this is only true of the simplest of ErrorKinds - those that have nothing except Msg(String) - so I don't think it's worth it.

This is a breaking change that requires bumping to v0.11.0 Luckily error-chain is going to go to v0.11.0 as well, so the timing might work.

---

Alas, there's another breakage that #[macro_use] extern crate error_chain; also conflicts with the custom derive name and the attribute name. Just renaming the custom derive is not a complete solution. Looks like the attribute will need to be renamed after all...

Allow backtrace to be optional

Instead of a feature, it should be part of the top-level attribute, eg #[error_chain(backtrace = false)]

Ref: rust-lang-deprecated/error-chain#56

Future alias?

pub type Future<T> = ::futures::Future<Item = T, Error = Error>;

like the Result alias.

Opt-in via toplevel #[error_chain(future)] / #[error_chain(future = "Future")] attribute, of course.

Switch to new proc_macro_derive

• Usage becomes #[proc_macro_derive(error_chain, attributes(error_chain))]

• The ErrorKind enum will be emitted automatically with the error_chain attributes stripped.

Ref: rust-lang/rust#35900 (comment)

Add `const("some string literal")` as a shorthand for `description()`

As a workaround, one can use a closure instead of a function path:

#[derive(Debug, error_chain)]
pub enum ErrorKind {
	Msg(String),

	#[error_chain(custom, description = "http_status_description")]
	HttpStatus(u32),
}

fn http_status_description(_: &u32) -> &str {
	"http request returned an unsuccessful status code"
}

can be written as

#[derive(Debug, error_chain)]
pub enum ErrorKind {
	Msg(String),

	#[error_chain(custom)]
	#[error_chain(description = r#"(|_| "http request returned an unsuccessful status code")"#)]
	HttpStatus(u32),
}