Resolve warning: macro-expanded 'macro_export' macros from the current crate cannot be referred to by absolute paths

[iamjpotts]

Building this crate or a crate that depends on this crate with rust 1.91 (which became stable today) results in this warning:

cargo +1.91 b

warning: the following packages contain code that will be rejected by a future version of Rust: num-bigint-dig v0.8.4, russh v0.54.6 
note: to see what the problems were, use the option `--future-incompat-report`, or run `cargo report future-incompatibilities --id 1`

Running the report shows several warnings such as:

> warning: macro-expanded `macro_export` macros from the current crate cannot be referred to by absolute paths
>   --> russh/src/client/session.rs:7:13
>    |
>  7 | use crate::{map_err, msg, ChannelId, CryptoVec, Disconnect, Pty, Sig};
>    |             ^^^^^^^
>    |
>    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
>    = note: for more information, see issue #52234 <https://github.com/rust-lang/rust/issues/52234>
> note: the macro is defined here
>   --> russh/src/helpers.rs:58:1
>    |
> 58 | / macro_rules! map_err {
> 59 | |     ($result:expr) => {
> 60 | |         $result.map_err(|e| crate::Error::from(e))
> 61 | |     };
> 62 | | }
>    | |_^
> 

Moving the macro definition outside the scope of the include! macro in lib.rs fixes the warning, though it makes the macro definition an outlier vs how the rest of the code in this crate is organized.

One option is to move the Error definition and this macro into a new error.rs or errors.rs module that is referenced directly from lib.rs (and protected by the feature conditional compile expression).

Another alternative is to delete the macro, and adjust all uses of it to simply either use ? or where necessary, a .map_err(crate::Error::from)? expression.

Fixes #594

[amtelekom]

Alternatively, #[macro_export] could be completely removed, if the macro is just used inside of the russh crate (which it being hidden from the docs seems like the intention).
Instead, it can be made available to the other modules using pub(crate) use map_err; in the helpers mod, and then fixing the usings which right now expect the macro in the root module (use crate::map_err) to point to crate::helpers::map_err or adding a pub(crate) use helpers::map_err; in lib_inner.rs.

(Not that I prefer one way or the other, just to show another possible solution)

[iamjpotts]

Alternatively, #[macro_export] could be completely removed, if the macro is just used inside of the russh crate (which it being hidden from the docs seems like the intention). Instead, it can be made available to the other modules using pub(crate) use map_err; in the helpers mod, and then fixing the usings which right now expect the macro in the root module (use crate::map_err) to point to crate::helpers::map_err or adding a pub(crate) use helpers::map_err; in lib_inner.rs.

(Not that I prefer one way or the other, just to show another possible solution)

I tried all of those variants, since they seemed like the least change / closest to the status quo, and continued to get the warning while the macro was in something wrapped by include! - only moving it outside of include! fixed it.

[iamjpotts]

@amtelekom apparently there was one variant I had not tried. Poked it one more time a few minutes ago and got cargo +1.91 to not emit the warning with the macro still inside include! and helpers.

I can squish the two commits if desired.

[Eugeny]

LGTM now, thank you