Rename built-in crates

[emberian]

rand etc conflict with crates.io crates and causes confusion. We should rename them private_rand or rustc_rand etc.

[emberian]

I think we should rename:

• libc
• num
• rand
• log
• rbml
• term
• syntax
• serialize
• graphviz
• getopts
• flate
• arena
• alloc

[huonw]

I'm in favour. It seems like this might be something good to do for 1.0, since hitting errors about them can be quite confusing (especially without reasons, cc #25211).

[steveklabnik]

I'm 👍 to this, and backporting to 1.0

[SiegeLord]

This hasn't been done, and still results in bad user experience. Can this still be fixed post 1.0?

[steveklabnik]

Status update: this still isn't done. We do have some errors on the rustc_private feature saying "please use the crate from crates.io", which is helpful.

@rust-lang/compiler is this something we ever intend to do?

[SiegeLord]

The errors I hit happen way before that is hit. Here's an example error:

error[E0464]: multiple matching crates for `getopts`
 --> /home/siege/Projects/RustGnuplot/examples/common.rs:3:1
  |
3 | extern crate getopts;
  | ^^^^^^^^^^^^^^^^^^^^^
  |
  = note: candidates:
  = note: path: /home/siege/Projects/RustGnuplot/build2/getopts_dep/target/debug/deps/libgetopts-3facdbd0235704b0.rlib
  = note: crate name: getopts
  = note: path: /usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgetopts-9f0027fbffa38971.so
  = note: path: /usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgetopts-9f0027fbffa38971.rlib
  = note: crate name: getopts

You hit this when you use rustc directly without cargo, as cargo will disambiguate using the --extern flag for you. Doing it as a non-cargo user is a pain, however, since --extern takes the filename, and if the filename contains a hash created by cargo which changes at the drop of a hat, it's just a big pain to even construct the correct --extern argument.

[nikomatsakis]

I'd be in favor of doing this rename, I think. It seems odd to have the same crates in two places. But maybe @alexcrichton has plans to just move us over to the crates.io crates eventually or something?

[steveklabnik]

plans to just move us over to the crates.io crates eventually or something?

I think so, or at least, I'd be a big 👍 there

[alexcrichton]

Yes for any relevant crates I'd like to move to using the crates.io versions, but I don't think we'll ever get around to moving everything out of tree, just support libs and such.

[steveklabnik]

Update: we can now use crates.io crates, but not all crates that are on crates.io have been updated to those versions.

[cyplo]

Heya ! Hope you're having a beautiful day !

Any updates on this one ?

[Mark-Simulacrum]

I personally think this isn't really something we can/want to do anymore today, we depend on dozens of crates.io crates and place those in the sysroot today. Error messages on attempted use aren't great but that's an orthogonal issue.