Per https://github.com/rust-lang/rust/issues/38356#issuecomment-318607072 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...
Per https://github.com/rust-lang/rust/issues/38356#issuecomment-318607072 it is a compiler error to have a
proc_macro_deriveuse its name for anattributelike this crate does (#[derive(error_chain)]and#[error_chain(...)]) since the latter is also the syntax forproc_macro_attributemacros.#[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 ofErrorKinds - those that have nothing exceptMsg(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...