Added long diagnostics for E0254.

[uatach]

No description provided.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @pnkfelix (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[nham]

Unless I'm misunderstanding, I think you meant use foo here. The following example will compile:

// crate foo
pub struct Blub;

// some other program
extern crate foo
use foo::*;

fn main() {
  let _blub = Blub;
}

[uatach]

If you add pub mod foo; to the crate foo, it won't work.
That is what I meant by 'exported its own symbol', maybe I should change that?

[pnkfelix]

I would discourage reusing the same name foo for such totally different roles, unless it is strictly necessary for replicating this particular error diagnostic. Its okay for the example program to be a little bit longer, if it makes the example clearer. (Also, if I read this correctly, you are using the mod foo; form, but have not included the text of the associated foo.rs file that would hold the body of that module? That also seems overly difficult for the reader to understand; why not just put the definition of mod foo inline?)

[pnkfelix]

(i'm investigating this now; I can see that the most trivial examples of duplicate imported symbols flag other error codes, so let me see if I can tease out exactly what it is about your example that matters)

[pnkfelix]

Okay so here is what I think is a more direct example:

This works for any external crate, but I'll include a trivial one that provides zero exports. (But if you want to add a one line definition to it, that's fine, as long as its not named foo too.)

external crate foo.rs:

#![crate_type="lib"]

client code bar.rs:

extern crate foo; // this puts `foo` into the root type+module namespace

use inner_mod::foo; // this also tries to put `foo` in the same namespace

mod inner_mod {
    pub mod foo { }
}

And then one might note that this variant of bar.rs also has the same problem:

extern crate foo; // this puts `foo` into the root type+module namespace

use inner_mod::foo; // this also tries to put `foo` in the same namespace

mod inner_mod {
    pub type foo = i32;
}

[pnkfelix]

(we could remove the foo.rs entirely by referring to a crate that is always available. For example by using core everywhere that foo occurs in my example. But its probably better to explicitly include the foo crate itself, even if it is a trivial crate with no exports.)

[uatach]

I agree that it's more direct but it doesn't make clear that an import from an external crate can cause this problem too (and I say this because, reading your code, I wouldn't be able to figure out that the code I was writing were correct and the external lib I was using that exported something weird.)
Still, I will do some rewriting, thanks.

[bors]

☔ The latest upstream changes (presumably #27111) made this pull request unmergeable. Please resolve the merge conflicts.

[pnkfelix]

I am not sure I would personally have put both of the examples errors into a single example file, since if you show it this way, then removing the extern crate foo; above actually fails to yield code that will compile (since these two imports are themselves in conflict).

The only reason that I included both examples in my write up to you is because you (I think) had included two distinct examples in your original draft.

I would strongly consider either putting in both as separate examples, or just removing the variant that uses mod inner_mod { pub mod foo { } } and instead just use the one that exports a type.

[Gankra]

r? @Manishearth

[uatach]

I'm not sure, am I the one that must solve the conflicts?

[Manishearth]

Yes, if you know how. Otherwise I can rebase it for you ocne you address review comments

[Manishearth]

No need for this code example, it just confuses the situation

[Manishearth]

Any updates?

[alexcrichton]

Closing due to inactivity, but feel free to resubmit with a rebase!