support compiler switches for `std` feature

[brenzi]

If a crate has

#[cfg(feature = "std")]
use std::vec::Vec;

this shouldn't result in FAILURE because the compiler switch deactivates the use std::

[dbrgn]

I have a similar problem: I include tests like this.

#[cfg(test)]
mod tests;

The tests require std, which cargo-nono doesn't like.

$ cargo nono check --features asdf
at-rs: FAILURE
  - Source code contains an explicit `use std::` statement.
   --> src/tests.rs:18:4
    |
18  |use std::sync::Once;
    |    ^^^^^^^^^^^^^^^

[l0calh05t]

I'm running into what I assume is this issue when using wmidi in a no_std crate, where my Cargo.toml explicitly disables default features

[dependencies]
wmidi = { version = "4", default-features = false }

But cargo nono check fails with

wmidi: FAILURE
  - Source code contains an explicit `use std::` statement.
   --> <...>\wmidi-4.0.6\src\error.rs

  - Source code contains an explicit `use std::` statement.
   --> <...>\wmidi-4.0.6\src\midi_message.rs

The corresponding use statements are behind a cfg, e.g.

#[cfg(feature = "std")]
use std::error;

Interestingly, another crate (itertools) only fails if I enable default features.

[alxiong]

I'm running into a similar problem on num-bigint

└─○ cargo nono check
num-bigint: ❌
  - Source code contains an explicit `use std::` statement.
   --> src/lib.rs:119:4
    |
119 |use std::error::Error;
    |    ^^^^^^^^^^^^^^^^^
num-integer: ✅
num-traits: ✅

but apparently in the source code here:

#[cfg(feature = "std")]
use std::error::Error;

this issue is long-standing, any technical blocker preventing from being addressed? @hobofan

[hobofan]

@alxiong No explicit technical blocker, there is just no logic in place yet to track and evaluate compiler switches on individual use items (as evaluating arbitrary compiler switches was a rabbit hole I didn't want to go into).

I'm overall maintaining the project passively, but if someone were to make a PR for it, I'll review it.