Tracking issue for libcore prelude traits

[alexcrichton]

These are currently all unstable but part of the libcore prelude.

This is currently intentional, but the fact that they need to be unstable is somewhat unsettling. Arguably all unstable features in libcore should be on the path to deprecation or stabilization at some point.

[Mark-Simulacrum]

I believe that libcore is now mostly stable, aside from those below. As far as I can tell, none of these are directly in the prelude, though I may be wrong. Perhaps this can be closed?

   1 src/libcore/fmt/mod.rs: fmt_flags_align
   1 src/libcore/hash/mod.rs: sip_hash_13
   1 src/libcore/iter/range.rs: trusted_len
   1 src/libcore/iter/traits.rs: exact_size_is_empty
   1 src/libcore/iter/traits.rs: iter_rfind
   1 src/libcore/macros.rs: concat_idents_macro
   1 src/libcore/marker.rs: unsize
   1 src/libcore/slice/mod.rs: slice_get_slice
   1 src/libcore/sync/atomic.rs: compiler_fences
   1 src/libcore/sync/atomic.rs: future_atomic_orderings
   2 src/libcore/fmt/mod.rs: never_type_impls
   2 src/libcore/hash/mod.rs: i128
   2 src/libcore/iter/sources.rs: trusted_len
   2 src/libcore/iter/traits.rs: fused
   2 src/libcore/iter/traits.rs: trusted_len
   2 src/libcore/ops.rs: question_mark_carrier
   2 src/libcore/option.rs: option_entry
   2 src/libcore/ptr.rs: offset_to
   2 src/libcore/slice/mod.rs: trusted_len
   2 src/libcore/str/mod.rs: str_internals
   3 src/libcore/char.rs: try_from
   3 src/libcore/cmp.rs: reverse_cmp_key
   3 src/libcore/iter/sources.rs: fused
   3 src/libcore/ops.rs: fn_traits
   3 src/libcore/option.rs: fused
   3 src/libcore/option.rs: trusted_len
   3 src/libcore/result.rs: fused
   3 src/libcore/result.rs: trusted_len
   3 src/libcore/slice/mod.rs: sort_unstable
   3 src/libcore/str/mod.rs: str_mut_extras
   4 src/libcore/char.rs: decode_utf8
   4 src/libcore/char.rs: fused
   4 src/libcore/cmp.rs: never_type_impls
   4 src/libcore/convert.rs: try_from
   5 src/libcore/cell.rs: coerce_unsized
   5 src/libcore/char.rs: char_escape_debug
   5 src/libcore/num/mod.rs: try_from
   5 src/libcore/ops.rs: placement_new_protocol
   5 src/libcore/ptr.rs: unique
   6 src/libcore/iter/range.rs: fused
   7 src/libcore/iter/mod.rs: trusted_len
   7 src/libcore/mem.rs: manually_drop
   7 src/libcore/str/mod.rs: fused
   8 src/libcore/hash/sip.rs: sip_hash_13
   9 src/libcore/ptr.rs: shared
  10 src/libcore/ops.rs: coerce_unsized
  10 src/libcore/slice/mod.rs: fused
  10 src/libcore/str/mod.rs: str_checked_slicing
  14 src/libcore/slice/mod.rs: slice_rsplit
  20 src/libcore/iter/mod.rs: fused

[SimonSapin]

@Mark-Simulacrum How did you make this list? It’s missing at least core_slice_ext, core_str_ext, and core_char_ext for the core::slice::SliceExt, core::str::StrExt, and core::char::CharExt traits, which is what this issue is about. They are re-exported from libcore’s prelude, which is different from libstd’s prelude.

[Mark-Simulacrum]

I can't find the command in my history right now for some reason. I guess I messed up with the ripgrep parameters, though. No need for the list now though, since you've provided it :).

[nagisa]

We certainly should move non-allocating inherent slice methods into libcore as inherent methods, and not the trait mess we’re currently in.

I’m fairly sure we could hack the compiler enough to allow multiple inherent impl blocks across the libcore and libcollections crates with some attribute or something.

[Razican]

Hello, I'm seeing that the core_float feature redirects here. I found it out when trying to use f32::powi(). Why are float "power" methods not available in stable core? Do they need to allocate? Why?

[SimonSapin]

@alexcrichton Should core::num::Float be added to core::prelude::v1, following the same pattern as CharExt for example? This would make methods like powi available to no_std crates.

[alexcrichton]

In general yes, functionality stable in libstd is fine to ensure is available in libcore as well. Looking at the trait it also has a stable Bits associated constant though, which means the entire trait is probably not ready for stable reexportation.

[Razican]

I also see that for the cos(), sin(), sin_cos() and sqrt() functions in floats only use intrinsics readily available in core_intrinsics. Maybe those could be stabilized as well, right?

[alexcrichton]

Those are ones we'd specifically actually not want to stabilize as well because they require runtime support. Their definitions in libcore should likely be removed.

[michael-p]

So if one needs to use sin, cos etc on an embedded device (with implementations provided by libc/libm) one has to use core::intrinsics::sinf32 and friends, right? Or is there another (better) way of doing this, since core_intrinsics is probably never going to be stable? (meaning using trigonometric functions in the embedded world will never be stable)

[Razican]

I was thinking on porting parts of libm to Rust using corrode or something similar, since I also would like to have atan(), asin() and acos() too, and they use cmath in the standard library. I still don't know if I could make them work without heap allocation, though.

I ported most of some code to use core::intrinsics::sinf32 and friends, but @alexcrichton said they should likely be removed, so it's probably not a good idea to depend on them. I didn't try to compile them to bare metal, even though they compiled fine using #[no_std].

I haven't started any work on sqrt().

[alexcrichton]

@Razican for sure yeah it's useful to have in libcore but it should be explicitly improted. Something like core::intrinsics::sinf32 just calls sin, so that's why it's not exported.

[SimonSapin]

not want to stabilize as well because they require runtime support

@alexcrichton Does this also apply to the abs, signum, and powi methods of core::num::Float? Their impls are based on intrinsics.

[alexcrichton]

@SimonSapin yes ideally anything requiring runtime support is only stabilized in libstd, although that ship may have already sailed.

[SimonSapin]

The Float trait is unstable and not in the prelude, so… maybe not?

To be clear, what does "runtime support" mean here exactly? You seem to be suggesting it includes anything that calls into an LLVM intrinsic but as far as I can tell plenty of things in libcore do that.

[alexcrichton]

To me "runtime support" is "on any platform this lowers to a call to libm"

[SimonSapin]

Sounds good. Do you know how I can find out which intrinsics can lower to calls to libm?

[alexcrichton]

Unfortunately I'm not sure there's a great way other than "compile it for a bunch of platforms and see what LLVM does"

[SimonSapin]

The relevant intrinsics are:

• llvm.fabs.f32
• llvm.fabs.f64
• llvm.copysign.f32
• llvm.copysign.f64
• llvm.powi.f32
• llvm.powi.f32

The compiler-builtins crate has Rust implementations of __powisf2 and __powidf2, but in LLVM code those are only mentioned in lib/Target/WebAssembly/WebAssemblyRuntimeLibcallSignatures.cpp.

[SimonSapin]

#27823 moved a number of float methods (back) from libcore to libstd, but specifically left abs, signum and powi in libcore but doesn’t say why. (And the author hasn’t been active on github for several years.)

[SimonSapin]

#49896 replaces these traits with inherent methods.

[SimonSapin]

I’ve filed #50145 specifically for f32 and f64 methods in libcore.