extern crate is always treated as pub within the crate, but is not visible outside it; pub extern crate makes no difference

[brson]

Two examples:

#![feature(core)]
#![crate_type = "lib"]
pub extern crate core;

That is accepted but core cannot be accessed from outside the crate.

#![feature(core)]
#![crate_type = "lib"]

mod foo {
    extern crate core;
    // behaves identically
    // pub extern crate core;
}

pub use foo::core;

That is accepted and reexports core.

In other words, extern crate is always public to other modules, but can never be made public to other crates.

There are no tests for pub extern crate so I suspect this is not intentional.

[eddyb]

Also see #21757.

[nikomatsakis]

triage: P-high

We should nail this down. I'm assigning this to @nrc since iirc he last touched the privacy code. ;)

[pnkfelix]

(any reason we can't just ... make pub extern crate a parse error ... ?)

Update: (with a warning cycle in the release series, of course)

Update 2: Hmm, I guess I missed the point that it can also be reexported, so making pub extern crate illegal is probably not the right call. (that plus RFC 385 explicitly said it was making pub extern crate legal.)

[brson]

@pnkfelix Making it illegal might still be a reasonable stop-gap if it looks like we won't fix the problem for a while.

[nikomatsakis]

Can this be made into a hard error on nightly now?

[nikomatsakis]

Should we do a crater run? (with this marked as error)

Advice: if we do, please only make it an error if cap-lints is not provided.

[alexcrichton]

This has reached stable now, so I'd at least be fine going to a hard error! (pending crater)

[eddyb]

See #29654 for a more breakage-prone issue with extern crate privacy (more so than pub extern crate, which is pretty harmless atm).

[nrc]

I was looking at this today. Let me get specific with the issues:

1. extern crate is always treated as public within a crate
2. pub extern crate was no more public, currently it warns on use, the plan was to make it an error and fix later.
3. pub extern crate does not export outside the crate.

The RFC is a little vague - it states that extern crate should work in sub-modules as well as the crate root and that pub extern crate should make it public, which includes re-exporting it to other crates.

So, I thought, lets make extern crate just like use with respect to privacy. This does not work. Let me summarise how use/pub use work.

1. use imports a name into a module
2. pub use imports a name into a module and re-exports it as a name like items declared in the module. Note that in step one we don't make the imported name available as a private name, it is not re-exported at all.
3. I.e., privacy checking for imports is entirely a function of name resolution, not the privacy checking phase. So when we check that a path is accessible in privacy checking, we check only that the target is accessible, not that each segment is also accessible (because if any segment were not accessible, we could not name it). (Note that privacy of module 'literal's is checked slightly orthogonally to this).

If extern crate were to work like use, then a crate imported at the crate root would not be visible in child modules - clearly this breaks the world.

It seems the best solution is to treat extern crate more like inlining a module than importing a name. In this case, I think we get the expected semantics for pub and non-pub extern crate and the only back-compat hazard is where users have extern crate in a sub-module but refer to it from outside. However, this is not trivial because it doesn't fit with how we check privacy, iirc, we check from the target of a path until we either get to the 'caller' or to the global namespace, and error-ing out if we find a private module. With the extern crate change we have to check how the item was imported too. I think this is doable, but it's not as easy as I was expecting (also I don't understand the privacy code as well as name resolution).

Alternatively, we could probably leave things as is for now, perhaps carry on with the plan to make pub extern crate a hard error and fix this for 2.0 (since we want to re-architect name resolution any way, it might be easier to do later).

cc @petrochenkov since he has been looking at privacy.

[nrc]

and cc @rust-lang/lang

[Kimundi]

@nrc for what it's worth, the semantic I intended in the RFC was formulated under the wrong assumption that private use items exported a name from the module like other private items.

Since I see that aspect of use as another remaining inconsistency in the module system, and since it might change as part of a backwards compatible name resolution reachitecture, I'd be in favour of punting on resolving this for now until it is clear wether that change will happen or not. 😄

---

Some background:
The general vision I have for the module system is for all items (including use and extern crate) in a crate to behave identically in their interaction with it. That is to say, they all should be markable as public or private, and they all should follow the same privacy and reachability rules when referring to each other. If that vision is not achievable, I'd rather find a new consistent view than have stuff be partially implemented.

[nikomatsakis]

@nrc and I discussed a bit today. My feeling is that:

1. Like @Kimundi, I too want to make the semantics of use like all other items. But that seems like a bit of a distraction here. Whatever you think of use, you would probably agree that extern crate should act like other items in terms of being importable etc.
2. It seems like the move to warn on pub extern crate may not have been correct, or was at least too broad:
   • we probably want to warn if you do pub extern crate at the root level
   • but probably not at other levels, even though the behavior at non-root levels IS what you'd expect from pub extern crate
   • we probably don't want to warn at non-root levels because we don't want people to remove the pub if they expect access from outside the current module (which I would think is unusual, though it may occur)
3. I imagine that most people who put extern crate at any level other than the root intend for it to be privately used as an implementation detail. Anyway, it seems like we should fix this, but it also seems like a clear bug fix and hopefully one that won't lead to too much fallout.
4. Maybe the new privacy pass will make this easier to fix? Unclear.

[SimonSapin]

I’ve been using this pattern to simulate pub extern crate:

pub mod tendril {
    extern crate tendril;
    pub use tendril::*;
}