Feature to declare that a crate never can be "unused" when mentioned in extern crate

[est31]

Recently we got the unused_extern_crate lint (#42588). It still has an issue though with false positives around crates that contain natively linkable stuff, like -sys crates for example. The issue has been discussed in PR #42588 already, however it has been dismissed, because its a similar situation to the bad_style lint. There is a difference though, which is that you disable the lint at the declaration site, not the use site.

The difference became a very visible in my werk crate. I was having a bunch of integration tests each only linking to my werk crate to get the native API it offers, and I had to add #![allow(unused_extern_crate)] to every single integration test, while I had to allow the bad_style lint only in once place. That's not nice!

It would be cool if the false positive doesn't get fixed, there at least was a feature where I could do something with the werk crate so that the "unused" extern crate werk doesn't become a warning. This is not just interesting for my particular use case which is probably a bit niche compared to mainstream. Its also interesting if you look into the future (#44660), where #[allow(unused_extern_crate)] extern crate foo; becomes legacy, and you'd probably have to think about either having to add a way to disable the lint in Cargo.toml, or the only way to disable the lint will be globally for all dependencies by doing #![allow(unused_extern_crate)] in {lib,main}.rs. I think what I suggest is better than those two alternatives.

cc @aturon
cc @ishitatsuyuki

[ishitatsuyuki]

I agree. Currently I think you should be able to simulate this by using an allocator, but well it's destructive.

[ishitatsuyuki]

Sorry no I don't.

I only know one particular kind of false positive: usage of -sys crates just for linkage, such as git2->openssh.

I haven't dig into your case, but I'm not sure why you need to put it in all the tests. What's your linkage model?

[est31]

@ishitatsuyuki My use case has some components, including the tests, written in C, while others are written in Rust. For the tests, I took the original C tests and integrated them as cargo tests, so that I can run them using the superior cargo tooling (multiple threads, better output, etc.).

For the -sys crate, I don't really run bindgen, and in fact the C component calls into the Rust component. I try to avoid calling the other way round where possible.