Why would someone want to implement their own `core`?

Rust has #![no_core] which is perma-unstable.

It's used by core itself and I suppose could be useful if core wants to use crates on crates.io, then the crate will need to mark itself #![no_core]

When your crate is #![no_core], you don't get anything provided by Rust by default such as Copy so the compiler crashes, expecting language items to exist but they don't. You have to manually define necessary language item with #[lang_item] if you want to use them

#![no_core] can be useful to implement your own core. But why would anyone want to do this?

Are there any reasons why someone would want to mark their crate as #![no_core] aside from implementation of core itself?

It has to be used by core itself regardless of crates.io -- the compiler doesn't know anything about that.

It's also used in the testsuite for tests/auxiliary/minicore.rs and all the tests using that. A big benefit is that such tests can run in cross-compilation without bothering with the standard library.

No outside crates should use no_core -- perma-unstable features should be considered internal-only.

3 Likes