cargo features (verbose-errors may be other?) should be additive

[Dushistov]

As desribed rust-lang/cargo#4323, see @kennytm comment here:

The problem here is that, when using "simple errors", the type nom::simple_errors::Err<E> is simply a type alias of nom::ErrorKind<E>, while with "verbose errors" the type nom::verbose_errors::Err<E> is a dedicated enum, so the "with-feature" and "without-feature" interfaces are incompatible.

[kennytm]

#457 😢

[Geal]

yes, that situation is annoying, but I really don't see how to make that particular feature additive. Others (std, stream, regex*) are fine, but I don't know for this one.

[kennytm]

@Geal You could turn simple_errors::Err into an enum containing only the Code variant (preferably a non-exhaustive enum). It is fine as long as the API of simple_errors is a strict subset of verbose_errors.

Yes the fix is going to be a breaking change 😞

[Geal]

so this is now done as you said, with an enum. It's much cleaner to use :)

[rustonaut]

seems I have to switch to nom4, this just broke my crate 🤕 well at last I did learn something new

[leoschwarz]

This ended up biting me now too.

The docs here https://github.com/Geal/nom/blob/master/doc/upgrading_to_nom_4.md, at least pub type Err<E=u32> = ErrorKind<E>; should be updated to reflect the change made but I'm not sure if there is more that still needs updating.

[dtolnay]

I don't think this has been fixed. I still see this in master:

https://github.com/Geal/nom/blob/a88a6f8d3fe3cf41ef682bbfec1fd72f08edcf95/src/lib.rs#L434-L436

That means the following code would break if verbose-errors is enabled anywhere else in our dependency graph.

extern crate nom;

use nom::simple_errors;

Some cases of this causing breakage:

• A dependency compiles on it's own, but does not compile as dependency (lettre & nom)
• Macro failure only when depending on a project having bindgen as a build dependency.
• Build 0.8.2 fails to compile against nom 3.2.1

[rustonaut]

Hm, everything from `*_errors` is re-exported so the modules could be private. Alternatively re-exporting them through a common module name (`errors`) is also an option.

…

On Wed, Jun 27, 2018, 08:12 David Tolnay ***@***.***> wrote: I don't think this has been fixed. I still see this in master: https://github.com/Geal/nom/blob/a88a6f8d3fe3cf41ef682bbfec1fd72f08edcf95/src/lib.rs#L434-L436 That means the following code would break if verbose-errors is enabled anywhere else in our dependency graph. extern crate nom; use nom::simple_errors; Some cases of this causing breakage: - *A dependency compiles on it's own, but does not compile as dependency (lettre & nom)* <https://users.rust-lang.org/t/a-dependency-compiles-on-its-own-but-does-not-compile-as-dependency-lettre-nom/18097> - *Macro failure only when depending on a project having bindgen as a build dependency.* <rust-lang/rust-bindgen#1287> - *Build 0.8.2 fails to compile against nom 3.2.1* <lettre/lettre#298> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#544 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHR0kVO4zP5ULvPOOGhVcSj3L1zZTCy2ks5uAyJXgaJpZM4Oi-EM> .