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.

[joshtriplett]

Marking as "needs-summary", because we need a closer look at the use cases for #[no_core], and why it is that core can't "compile to nothing" to serve some of those use cases (macro-only crates aside).

[scottmcm]

no_core implies so many things -- no Add, no Fn, etc -- that it doesn't seem like the right way to expose whatever the goals here are. To me, no_core is perma-unstable, as it's there for internal reasons so will stick around but won't be stable.

That's not to say that there couldn't be other things that would make sense to have on stable, like a "please don't use simd" kind of flag/attribute or "I wish LTO worked better to remove parts I don't need" or ..., but those wouldn't be this issue.

[mamins1376]

In a recent embedded project, I needed to calculate CRC. I knew there is the crc crate which is quite minimal and meets every requirements.

The project is written mostly in C, so in order to save time, I exported a simple interface:

#[no_mangle]
unsafe extern "C" fn calculate_crc(data: *const u8, len: usize) -> u32 {
    ...
}

... and turned that into an object file with $ cargo rustc --release -- --emit=obj and simply linked it to the rest.

This had no dependency on core. Initially I declared the whole thing as #![no_core] but faced the mentioned missing lang items.

Does this count in any way?

[luke-biel]

no_core would defiintelly open up possibility of alternate core implementations. How useful would that be in current rust ecosystem - hard to tell. I could see this used in projects that require formal verification - eg. Ada limits it's stdlib for SPARK. But there may be better ways to achieve this.

[gheoan]

Should I be opening bug reports related to my use of no_core? I've seen confusing diagnostic messages and ICEs.

[petrochenkov]

@gheoan
ICEs need to be reported and fixed in most cases, even in no_core.

As for diagnostics, I don't think we should do anything for no_core-specific diagnostics, unless it's zero cost in terms of code added to rustc.

[eggyal]

ICEs need to be reported and fixed in most cases, even in no_core.

Contradicts #92495 (comment):

Personally, I don't think ICEs with #![no_core] are worth addressing. It's a perma-unstable feature, and lang items are effectively internal compiler code that happens to be written in a crate. We don't try to prevent ICEs in the face of modifications to the compiler itself (in fact, many internal compiler APIs will deliberately ICE when they are used incorrectly).

The only correct way to use #![no_core] is to copy-paste all of the lang items, types, and impls that you're using (and even then, leaving out "unused" ones is pretty dubious).

[scottmcm]

I think getting ICEs in no_core for not providing all the things is absolutely to be expected, and not something that needs to be fixed. For example, u32 is Copy, and if you don't include that and thus get an ICE, too bad. We should not expend any effort at all to improve that situation.

[tgross35]

I could see this used in projects that require formal verification - eg. Ada limits it's stdlib for SPARK. But there may be better ways to achieve this.

Imho, I think that it would be good to give Rust some hooks that would allow for use in safety-critical systems that could potentially eliminate the need for a separate core (for at least the basic SIL levels) - which would probably have benefits to the language as a whole. Some things I've considered that would help that -

• #![no_panic] being used to classify a any potential panics as UB. This would be pretty useful as a sanity check too throughout the language, #[no_panic] tags could be added to a lot of core/std functions for the compiler to verify (this would be useful in kernel space too)
• Some way to disallow unchecked casts and arithmetic
• Some sort of way to programatically tie unsafe blocks to the code that makes them safe. I'm stealing a bit from Ada contracts here where you can have a syntax like with Pre => Name'Length > 0 for a function definition, indicating a precondition to make that function valid. It would be pretty awesome if you could do that sort of thing for any unsafe fn, indicate a precondition and make the caller indicate the lines where they check that brecondition to be true.

The first two things are basically clippy lints, but they would need to be applied recursively to everything linked. Stack size analysis is another thing, but this is already sort of coming via stack_sizes. It would be interesting to reach out to Ferrous Systems and see what the people there have to say on the subject.

Regarding the cfg-if thing, is there any reasons the implementations aren't just exported from core?

[joshlf]

@kotauskas

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.

IIUC you might want to have core depend on an external crate for its implementation without exposing that crate's API in core's API. E.g., per @gnzlbg, "we currently duplicate cfg-if in libcore, libstd, stdsimd, and in libc" - even if we don't intend to expose cfg-if's API anywhere in the standard library, it would still be a boon to allow libcore, libstd, stdsimd, and libc to depend on a single crate rather than duplicating code across their implementations.

[Cerber-Ursi]

it would still be a boon to allow libcore, libstd, stdsimd, and libc to depend on a single crate rather than duplicating code across their implementations.

If I understand the argument correctly, it is essentially "except core, they all already depend on a single crate, namely core itself".

[LegNeato]

I think I have a use-case for this. I want to specify a logical data model using Rust's syntax and type system so that implementations can map in and out (a la serde). It is important to keep it zero-sized to maintain maximum flexibility for both the people mapping in and out as well as the end users relying on those crates.

I want to mark my definition crate as #[no_core] so the compiler automatically guarantees I don't accidentally depend on a specific storage implementation detail such as u64.

I can achieve my overhead and compatibility goals by sticking to const, but a) there's no guarantee that const happens at compile time and b) even if it was guaranteed to run at compile time, there is not something like #[const_only] to have the compiler make it so I don't inadvertently introduce something non-const wrapping the const in the future.

[scottmcm]

I want to mark my definition crate as #[no_core] so the compiler automatically guarantees I don't accidentally depend on a specific storage implementation detail such as u64.

u64 is a magic primitive, not something from core, so it'll still be there even in no_core. (And the correct way to do type restrictions is with traits, not trying to remove them from existence.)

[LegNeato]

u64 is a magic primitive, not something from core, so it'll still be there even in no_core. (And the correct way to do type restrictions is with traits, not trying to remove them from existence.)

Right, but if I make a NoCore trait I can't tell the compiler to enforce that I am not using anything from core either in the trait or for my items that impl it.

One could informally not use std and have the same observable effects (minus linked std which might be stripped), but the existence of an optional #[no_std] is a strictly better alternative as invariants are enforced by the compiler. I don't see how core is different, other than the fact that there are fewer uses of #[no_core].