Tracking issue for libcore + no_std stabilization

[alexcrichton]

This issue is intended to represent the outstanding issues for stabilizing libcore and allowing its usage on stable Rust. There are a number of features currently associated with libcore:

• core
• core_char_ext
• core_prelude
• core_slice_ext
• core_str_ext

(note that core_float will be handled in a separate issue)

The design of libcore largely mirrors that of the standard library (good) but there are a few deviations:

• core::atomic differs from std::sync::atomic
• Modules like nonzero, panicking, and array are public

Overall there are a number of tasks that probably need to be done before stabilizing these items:

• A full audit should be done to ensure that the structure of libcore is the same as the structure of libstd
• The name core needs to be agreed upon as the stable name for the library
• The set of extension traits for primitives needs to be decided upon. This strategy of trait-in-core and inherent-above-core should be agreed upon as the best path forward.
• The set of items in the prelude should be audited to ensure it's a subset of the standard library's

[alexcrichton]

I think that all the major issues here have been resolved, so I'm nominating this for stabilization in 1.5

[bluss]

Is it possible to support multiple impl primitive blocks, so that core doesn't have to use as many extension traits?

[alexcrichton]

Not currently that I'm aware of at least, and that would definitely be part of the stabilization aspect of this issue.

[aturon]

Idea: mark the methods on the extension traits as stable, but leave the traits themselves unstable. Works because they're in the prelude. (We did this for SliceConcatExt.)

Not a great permanent story, but it's a place to start.

[brson]

I want to understand the story for undefined symbols before making this stable. There's a real possibility of people defining these themselves in ways that aren't forward compatible.

[alexcrichton]

This issue/feature is now entering its cycle-long FCP for stabilization in 1.5

---

@brson, we currently have very few undefined symbols actually:

$ nm -u libcore*

core-10cbabc2.0.o:
                 U fmod
                 U fmodf
                 U memcmp
                 U memcpy
                 U memset
                 U __powidf2
                 U __powisf2
                 U rust_begin_unwind
                 U rust_eh_personality

Of these, rust_begin_unwind and rust_eh_personality are verified by the compiler to exist in the form of a lang item (e.g. it's unstable to define them) whenever you're producing a staticlib, executable, or dylib, so we're covered on that front. The memcmp, memcpy, and memset functions are lowered to by LLVM and I think it's safe to say that our reliance on their meaning will never cause breakage. The __powi{d,s}f2 function dependencies may disappear but otherwise they're provided by compiler-rt so I don't think we have to worry about them.

Otherwise, the only symbols we rely on are fmod and fmodf and that in turn is only because Div and Rem must be implemented in libcore instead of being able to define them in libstd for floats. I'm personally comfortable with this because --gc-sections makes the dependency go away and the symbols also have very well known meanings.

Do you have further concerns in light of this information?

[alexcrichton]

Oh and as a further clarification that I forgot to point out, this would also involve stabilizing #![no_std]. As a result I'm tagging this T-lang and renominating to make sure it comes up in triage over there. Triage in all the teams!