Tracking issue for `no_core` stabilization

[aturon]

The no_core feature allows you to avoid linking to libcore.

[ahmedcharles]

Perhaps it would be better to give this a 'positive' name, like [freestanding]?

[eefriedman]

no_core is basically useless on its own at the moment; you need lang_items to actually implement enough of the core traits to allow compiling anything non-trivial.

[steveklabnik]

Traige: no change

[gnzlbg]

no_core is basically useless on its own at the moment; you need lang_items to actually implement enough of the core traits to allow compiling anything non-trivial.

#[no_core] is super useful: some crates do not use any lang items and compile just fine (e.g. cfg-if), and if these crates aren't #[no_core] then we can't use them as dependencies of libcore, which means we have to duplicate them. For example, we currently duplicate cfg-if in libcore, libstd, stdsimd, and in libc (EDIT: and probably in hashbrown as well, that's 5 times that this macro is duplicated).

If we make cfg-if #[no_core] we can just add it as a normal cargo dependency to all those crates, and everything "just works". But we can't make it #[no_core] because it is not stable.

[Ericson2314]

@gnzlbg makes a great point.

Additionally I'd like it if it was renamed to not mention the name of any create. If we get core depending on more crates, core might not seem so core-y. Something like no_dependencies is more future proof.

On the other hand, maybe we'll someday want to make primitives like float only available from come crate, removing them from the ambient prelude. That would mean the current name is more forward compatible after all.