Rustdoc fails with info about symbol names

[alexcrichton]

A bunch of my nightly builds are now generating the error:

error: the current crate is indistinguishable from one of its dependencies: it has the same crate-name libc and was compiled with the same -C metadata arguments. This will result in symbol conflicts between the two. [E0519]

This is likely due to the revamp of symbol names, but it's also unfortunately a regression on nightly. I think what's happening here is that Cargo isn't passing -C metadata to rustdoc (because it can't) and then the crates.io libc crate is conflicting with the in-tree libc crate.

cc @nikomatsakis

[alexcrichton]

Ah, and an example of a failing build

[brson]

I'm hitting this too.

[nikomatsakis]

cc @michaelwoerister

[nikomatsakis]

@brson specifically with libc, or with other crate names?

[nikomatsakis]

So I'm trying to figure out if the right answer here is that we should just be passing in metadata to rustdoc? Seems plausible.

[michaelwoerister]

Hm, in rustdoc we actually don't care about symbol name conflict, so we could indicate that to the crate loader?

[michaelwoerister]

The analysis of the underlying reason by @alexcrichton seems plausible to me, by the way.

[nikomatsakis]

Hm, in rustdoc we actually don't care about symbol name conflict, so we could indicate that to the crate loader?

Maybe, but it seems sloppy to me -- I mean, why don't we care? The signatures might well be different, for example, so it might well matter. In any case, I'm trying to understand what is leading us to get this conflict still (I haven't reproduced it yet -- what target do I need to use?).

The analysis of the underlying reason by @alexcrichton seems plausible to me, by the way.

I feel like I'm still missing something. From what I can tell, the error comes when generating docs for the libc crate -- so why is it accessing crates.io anyway? And doesn't crates.io give metadata when building? (Do we tell rustdoc where to find all dependencies the same way we tell rustc? I would expect so...but maybe it's falling back to some other behavior and scraping things off the file system?)

Perhaps part of it is that I am a bit removed from the details of how a lot of this lower level stuff works.

[nikomatsakis]

ok, I see now that this error is not when bootstrapping.