Libcore and libstd split, with linking to core by default.

[pcwalton]

It would be nice for developer ergonomics (not to mention marketing) to include a std::pervasives that's imported by default. Obvious things to go in there are print and option.

We'll need to have rustc figure out where the stdlib is and add a --nostdlib option for bootstrapping.

[marijnh]

So I guess we'll be moving things like getopts, term and ebml stuff out of the stdlib? It has to be small if it's linked with every single program.

[brson]

We could split the pervasives out into librustperv, add a --noperv flag, and reexport them from std.

[jdm]

That would be an... unfortunate... abbreviation.

[rpearl]

I like the name prelude (or maybe toplevel) instead of "pervasives", especially given that abbreviation...

[pcwalton]

librustpervasives?

[graydon]

Might I suggest "core"?

[marijnh]

+1 for core.

I guess these would consist of a bunch of modules magically present at the top level (::option). If we put them in a synthetic scope one level above the crate scope, you'd be able to shadow them with your own stuff if they get in the way.

This would also solve the issue of '#fmt' and '#[test]' not working when you don't use std

[graydon]

I just figured we'd add an implicit "use core (uuid=, vers=); import core::*;" to any crate not compiled with --no-core or such.

[marijnh]

That sounds about right, but I still think defining or importing another vec or str at the crate level should shadow core, rather than causing a collision error.

[brson]

Doing things like reexporting core::option::t as core::option requires #1115

[graydon]

empty not-yet-linked-by-default libcore landed in 447414f

[graydon]

libcore is now implemented, used and imported by default, and contains a pile of stuff moved from std. I'll carry on with movement and tuning of it but I think this bug can close now. I'll file subsequent bugs per-issue related to its contents.