`macro_rules_attribute-proc_macro` 0.1.4 is not backward compatible

[kpreid]

Create this source file:

macro_rules! MyDerive {
    ( $( $unused:tt )* ) => {};
}

#[macro_rules_attribute::macro_rules_derive(MyDerive!)]
pub enum Example {}

Create this Cargo.toml dependency:

[dependencies]
macro_rules_attribute = "0.1.0"

Then modify the lockfile using either cargo +nightly update -Z direct-minimal-versions or cargo update --precise 0.1.0 -p macro_rules_attribute.

Compilation will then fail with the error:

error[E0433]: failed to resolve: could not find `Custom` in `macro_rules_attribute`
 --> src/lib.rs:5:1
  |
5 | #[macro_rules_attribute::macro_rules_derive(MyDerive!)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ could not find `Custom` in `macro_rules_attribute`
  |
  = note: this error originates in the attribute macro `macro_rules_attribute::macro_rules_derive` (in Nightly builds, run with -Z macro-backtrace for more info)

This does not happen if macro_rules_attribute-proc_macro is at 0.1.3 or lower. So, the new macro_rules_attribute-proc_macro 0.1.4 breaks its dependent macro_rules_attribute 0.1.0.

[danielhenrymantilla]

Ah yeah I had once theory-crafted that this proc-macro pattern should be using = constraints.

Option 1

1. make a proper 0.2.0 release (henceforth using = constraints for the double-crate pattern)
2. yank 0.1.4;
3. make a 0.1.5 release which reverts back to 0.1.3 ("polite yanking").

This would break the new 0.1.4 users without a .lock file.

Option 2

1. yank 0.1.0 .. 0.1.4.

This breaks the low MSRV users without a lock file.

Other options?

@kpreid what do you think?

[kpreid]

This shouldn't break anyone: Option 1 but you make a macro_rules_attribute 0.1.5 release which depends on macro_rules_attribute-proc_macro 0.2.0.

More generally: = dependencies are not necessary (though they may be convenient) if you instead allow the proc-macro crate to have separate major versioning.

[danielhenrymantilla]

Ah, very nice idea. Done that for 0.1.5, but I've also released 0.2.0, since I find it simpler to keep both versions being bumped in lockstep. Thanks for the report and the idea!