Fix false positive for multi dep single use statements

[Elrendio]

Resolves #91

This also resolves some false detections of not_my_dep::my_dep_name::stuff_in_my_dep 😊 I couldn't find a way to avoid detection of futures in with the single line regexp

pub use {
    async_trait::{mod1, dep2},
    not_futures::{
        futures::{futures_mod1, futures_mod2::{futures_mod21, futures_mod22}}
    },
    reqwest,
};

This update does come at a small performance downside (that might be resolved by not instantiating a regexp per dependency?). On our repo of ~500k lines of machete goes from ~45s user time to ~48s of user time.

[bnjbvr]

Thanks! Just want a bit more comments, please.

[bnjbvr]

Can we keep the previous formatting here? It's weird to read on two lines.

[bnjbvr]

Ditto

[bnjbvr]

Suggested change

	// In order to avoid false usage detection of `not_my_dep::my_dep` the regexp unsures that the
	// In order to avoid false usage detection of `not_my_dep::my_dep` the regexp ensures that the

[bnjbvr]

It's already a nice comment, but can I ask for a little bit more please: could you take each part of this regular expression, and tie it to the comment? (Which part is 1. in your list, 2. in your list, etc. and feel free to add more comment sections if necessary)

[Elrendio]

I've linked the different parts 😊

[Elrendio]

Hi @bnjbvr ,

Sorry for the delay, I missed your comments 😞 I've addressed them and added a .rustfmt.toml that seems to mostly fit with your expectations in order for other contributors to follow your lint rules automatically. If you're not aligned I can remove it.

Have a nice day!

[bnjbvr]

Thanks! I'm not a huge fan of the custom .rustfmt.toml, so I'll get rid of it.

Thanks a lot for the comments, they make the regular expression slightly easier to understand (what a monster have we created here, now wondering if using a custom Rust syntax parser written with nom would be easier…).

I've tried it out on one of my favorite Rust projects wasmtime:

• wall clock time took a 18% slowdown hit, from 720ms -> 856ms
• user time took a 35% slowdown hit, from 2.7s -> 3.67s

While these are impressive in terms of relative numbers, since the tool is still running in less than a second on such a large code base, I consider it fine, especially since it's correcter (and what's the point of being fast if code isn't correct).

Merging, thanks a bunch 🙏