Frivolous private_in_public lint when shadowing an imported crate using #[bench]

[lambda-fairy]

I've encountered an issue with the private_in_public lint (#34537). If I create a #[bench] function that has the same name as an extern crate, then rustc claims that "extern crate foo is private".

Here's a minimal example that reproduces this bug:

// ducks.rs
#![feature(test)]
extern crate test;
extern crate geese;

#[bench]
fn geese(_: &mut test::Bencher) {}

geese.rs is an empty file.

$ rustc geese.rs --crate-type rlib
$ rustc ducks.rs --test --extern geese=libgeese.rlib
warning: extern crate `geese` is private, and cannot be reexported (error E0364), consider declaring with `pub`, #[warn(private_in_public)] on by default
  |
  = 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 #34537 <https://github.com/rust-lang/rust/issues/34537>

The warning disappears if I either (a) rename the bench function, or (b) remove the #[bench] attribute.

Using rustc 1.13.0-nightly (4f9812a59 2016-09-21), installed on Arch Linux x64 via rustup. (The official nightly hasn't been updated for a while, which is why my version is out of date. Apologies if the issue has already been fixed.)

[petrochenkov]

This is already fixed on nightly, but you have to enable new import resolution rules for the fix to have effect:

#![feature(item_like_imports)]

[lambda-fairy]

@petrochenkov Thanks for the tip. But I do wonder what we can do to make this warning less confusing.

[petrochenkov]

I do wonder what we can do to make this warning less confusing.

cc @jseyfried
(I'm not sure if it's reasonable to add some temporary diagnostics here or not, the name("bench-fn") == name("something from type namespace") situation doesn't seem to be common.)

[jseyfried]

I think there are two issues here. First, this doesn't compile at all with --test:

#[test] fn foo() {}
mod foo {} //< This causes the test harness's `use` of `foo` to be a hard re-export error.

This will be fixed by #![feature(item_like_imports)].

Second, this emits PRIVATE_IN_PUBLIC warnings with --test:

#[test] fn foo() {}
extern crate foo {} //< This causes the test harness's `use` of `foo` to be a `PRIVATE_IN_PUBLIC` warning.

This will not be fixed by #![feature(item_like_imports)] due to for backwards compatibility constraints from #26775. Once we stop allowing extern crates to be re-exported with more visibility, it will be fixed with #![feature(item_like_imports)].

[jseyfried]

With #![feature(item_like_imports)], we could mitigate PRIVATE_IN_PUBLIC issue by re-exporting the test harness function with pub(crate) visibility. That way, extern crates at the crate root would not be re-exported with extra visibility.