Tracking issue for internal feature `no_core`

[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.

[kotauskas]

This idea seems fishy and impractical for me, let me quote @Ericson2314 to elaborate why:

If we get core depending on more crates, core might not seem so core-y.

If core requires a certain crate for its convenience features and that crate is small enough to be used by core and to not depend on core at all, then why wouldn't core just include that crate into itself as an RFC to the language as a whole? If core depends on such a crate, therefore all of its members are linked to core and take the disk space in the final executable, meaning that not there's totally no reason to avoid using such a crate even if it's used only briefly in a very specific place where it's not that necessary which is why people rewrite a subset functionality from existing crates themselves for their specific use case.

This is not true for procedural macros, which are loaded into the compiler when core itself is compiled but are completely transparent to the final application, but either way there's the problem with the "standard" part in "standard library". The point of it is to provide utilities and core language features which are useful in a wide range of programs. Now, admittedly, cfg_if performs conditional compilation which is typically only used in abstractions over platform-specific code and that is supposed to implemented by a few crates and then reused by many other crates, meaning that the total amount of code which uses cfg_if is relatively low. But since it's such a small thing which was found useful in core, maybe it can become part of its public API, solving the duplication problem, providing access to its (unchanging!) interface for all Rust programs and promoting the use of it in a wider range of crates, improving readability. no_core would only promote hiding useful macros as private dependencies of core instead of promoting those macros becoming a part of Rust.

[ojeda]

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".

Please don't make core depend on anything unless there is a very good reason for it, much less on external repositories or on a particular build system.