Discrepancy between compilation of crates and single-file executables.

[nwin]

I have two files:

module.rs

#[main]
fn main() {
    println!("{}", std::str::from_utf8_lossy(b"Hello, world!"));
}

lib.rs

#![crate_id = "testcrate"]
#![crate_type = "bin"]

mod module;

rustc module.rs compiles without any problems. rustc lib.rs yields the error message:

module.rs:3:17: 3:42 error: unresolved name `std::str::from_utf8_lossy`.
module.rs:3     println!("{}", std::str::from_utf8_lossy(b"Hello, world!"));

[alexcrichton]

The phenomena you're seeing here is that extern crate std is injected at the top of every crate, so the crate root has the name std in scope by default. When you move it to a different module you enter a different namespace, so you'd have to import std again via use std;

[ben0x539]

I sort of think we should always put extern crate symbols in the top-level scope, and only them, and put the crate root into an implicit scope (maybe addressable as ::crate, and injecting use ::crate::* into every module...) below that, so the experience would be consistent between code in the crate root and code in a module, but I guess that gain in consistency might not be worth rejuggling everything and introducing more subtleties, and the impact on intra-crate use items makes it a nonstarter.

[pnkfelix]

@ben0x539 your suggestion sounds very much to me like rust-lang/rfcs#110 ; can you elaborate on where it differs? Or are they indeed the same idea?

[ben0x539]

@pnkfelix I think I descibred that really badly. I'm basically suggesting that given extern mod foo;, we stop accepting foo::... and require ::foo::... (or use foo; before foo::...), so making all crate items require absolute paths even when referencing them in the crate root. I would also then suggest not allowing extern crate items outside the crate root so they all exist in the outermost scope. I'm basically weirded out by external crates seemingly being nested within the current crate next to any normal item, rather than existing on the same nesting level as the whole of the current crate. The more I think about it, the less this whole plan sounds like a good idea, though.

That wouldn't address the problem that rust-lang/rfcs#110 tries to solve at all, you'd still need a mechanism to ensure that the same crate is referenced by the same path in completely different compilation units.

[steveklabnik]

This is the kind of item which would require an RFC to change, I'd think. Feel free to persue this over there!