Now that we are thoroughly embedded in libcore, we don't need these on by default.
Indeed, their presence may provide confusing results during integration attempts.
Another approach that fixesrust-lang/portable-simd#223, as an alternative to rust-lang/portable-simd#238.
This adds the `ToBitMask` trait, which is implemented on a vector for each bitmask type it supports. This includes all unsigned integers with enough bits to contain it. The byte array variant has been separated out for now into rust-lang/portable-simd#246 and still requires `generic_const_exprs`, but the integer variants no longer require it and can make it to nightly.
* Explain unsafe contracts of core::simd
This permeates the module with remarks on safety for pub methods,
layout of the Simd type, correct use of intrinsics, et cetera.
This is mostly to help others curious about how core::simd works,
including other Rust contributors, `unsafe` library authors,
and eventually ourselves.
Remove overflow panic from divrem and add basic docs to Simd<T, N>
This finishes normalizing Simd<T, N> to being approximately equivalent to Simd<Wrapping<T>, N> for all implemented operations I can think of. It also documents this fact, allowing this to closerust-lang/portable-simd#56.
The way the macro expands, it may sometimes infer
"this is a uint, but doesn't impl Neg???"
Also, I made the "wrong path for intrinsics" error.
These fixes allow integration into libcore.
impl std::simd::StdFloat
This introduces an extension trait to allow use of floating point methods
that need runtime support. It is *excessively* documented because its mere
existence is quite vexing, as the entire thing constitutes a leakage of
implementation details into user observable space. Eventually the entire
thing will ideally be folded into core and restructured to match the rest
of the library, whatever that structure might look like at the time. This
is preferred in lieu of the "lang item" path because any energy the lang
items require (and it will be significant, by Simulacrum's estimation) is
better spent on implementing our libmvec.
