Enabling `unstable-provider-api` breaks build of dependencies that does not declare the crate attribute

[bitdriftr]

Let's say I have :

• Crate A which depends on snafu without unstable-provider-api, thus it does not declare #![feature(error_generic_member_access)]
• Crate B which depends on snafu with unstable-provider-api, and does declare #![feature(error_generic_member_access)]
• Crate C which depends on A and B.

In that situation :

• Crate A builds standalone without issue
• Crate B naturally only builds on nightly
• Crate C cannot be built at all. It's because enabling the unstable-provider-api will affect generated code in crate A, which will then reference the unstable feature, but still does not declare #![feature(error_generic_member_access)] in lib.rs.

All of this is mostly a limitation when combining macros and features, but I wonder if it could be possible to fix it, by not referencing the nightly feature in generated code, but only in snafu's library code itself.

[shepmaster]

Oof. This is super annoying!

fix it, by not referencing the nightly feature in generated code, but only in snafu's library code itself

Yeah, that was my first thought as well, but unfortunately we need to implement the Error::provide method, which can't be routed through the SNAFU library crate.

My next thought was to only implement Error::provide based on some condition, such as if there are any explicit snafu(provide) attributes, but that will also suck because then we wouldn't generate the code to chain to the inner error, which would really limit the usefulness of the provided values.

I don't have a great idea right now. I'm poking the libs team to see what could be done to stabilize the feature, as that might be the "easiest" route forward!

However, the current state is junk because if SNAFU is used a lot (and that's the goal!) then the chances of this happening just keeps increasing.