Fixes #30089

[jseyfried]

r? @nikomatsakis

[jseyfried]

This fixes regression #30089 created by PR #29530, which caused intra-crate extern crate declarations to be treated like public items, as described in #26775.

In fact, in stable Rust an intra-crate extern crate declaration is treated like a public item during privacy checking (i.e. it is not privacy checked) and when resolving non-glob imports, but not when resolving glob imports. That is, one can always non-glob import an extern crate but one may never glob import an extern crate.

For example, this is legal:

mod foo {externcrate core;}pubuse foo::core;fnmain(){use core;}

but not this:

mod foo {externcrate core;}pubuse foo::*;fnmain(){use core;}

[jseyfried]

This behavior used to be caused by this function, which had been used exclusively to create bindings for the Modules corresponding to intra-crate extern crates. The function created private bindings for these modules, which are public; everywhere else, we respect the module's visibility when creating bindings.

When I refactored the function away, bindings for extern crates became public, allowing them to be glob imported. I just checked that the only other time the visibility of an extern crate binding matters is when computing LastPrivate data for the privacy checker, which currently does not check extern crates.

[alexcrichton]

@bors: r+ 15b1f56

Thanks!

[bors]

⌛ Testing commit 15b1f56 with merge d5321f2...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt