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.

[nikomatsakis]

Further investigation reveals that somehow we do not seem to be supplying -C metadata except for tests. Oops. That will presumably fix this conflict, though not in the best possible way -- because now the makefile libc will have a disambiguator, so the rustdoc version would have a disambiguator of just "" and everybody is happy.

That said, it seems to me that rustdoc should take a -C metadata argument -- presumably it should take the same arguments as rustc, since it basically invokes rustc.

[michaelwoerister]

Cargo isn't passing -C metadata to rustdoc (because it can't)

@alexcrichton Can you elaborate on that?

[alexcrichton]

I believe this is fixed in #32560, explained here: #32560 (comment).

To elaborate on the lack of metadata, rustdoc simply doesn't accept -C flags, so that's why it's not being passed :)

[nikomatsakis]

@alexcrichton did you actually check whether this is fixed? I wonder if it's worth trying to allow rustdoc to accept -C metadata -- I guess so long as it doesn't matter, it doesn't matter.

[alexcrichton]

Nah I was hoping to test with today's nightly, but that's blocked on #32568. I'm pretty confident that the change would fix this, however.

[paukul]

FYI rustc 1.9.0-nightly (b678600 2016-03-29) fixed this issue for me