| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Update stdsimd module
Pulls in a redesigned `std::simd` module as well as a replacement for the
`is_target_feature_detected!` macro
|
|
rephrase UnsafeCell doc
As shown by discussions on users.rust-lang.org [[1]], [[2]], UnsafeCell doc is not totally clear. I tried to made the doc univocal regarding what is allowed and what is not. The edits are based on my understanding following [[1]].
[1]: https://users.rust-lang.org/t/unsafecell-behavior-details/1560
[2]: https://users.rust-lang.org/t/is-there-a-better-way-to-overload-index-indexmut-for-a-rc-refcell/15591/12
|
|
|
|
|
|
Required moving all fulldeps tests depending on `rand` to different locations as
now there's multiple `rand` crates that can't be implicitly linked against.
|
|
Pulls in a redesigned `std::simd` module as well as a replacement for the
`is_target_feature_detected!` macro
|
|
|
|
|
|
|
|
|
|
based on @nikomatsakis texthg
|
|
Add a potential cause raising `ParseIntError`.
Initially, I wanted to add it directly to the documentation of `str. parse()` method, I finally found that it was more relevant (I hope so?) to directly document the structure in question. I've added a scenario, in which we could all get caught at least once, to make it easier to diagnose the problem when parsing integers.
|
|
|
|
|
|
Closes #43738.
|
|
|
|
|
|
Rollup of 14 pull requests
- Successful merges: #48403, #48432, #48546, #48573, #48590, #48657, #48727, #48732, #48753, #48754, #48761, #48474, #48507, #47463
- Failed merges:
|
|
Stabilize FusedIterator
FusedIterator is a marker trait that promises that the implementing
iterator continues to return `None` from `.next()` once it has returned
`None` once (and/or `.next_back()`, if implemented).
The effects of FusedIterator are already widely available through
`.fuse()`, but with stable `FusedIterator`, stable Rust users can
implement this trait for their iterators when appropriate.
Closes #35602
|
|
New Cell docs
This fixes https://github.com/rust-lang/rust/issues/44061
|
|
doc: no need for the reference
Also, we are well within line length limit
|
|
Add functions for reversing the bit pattern in an integer
I'm reviving PR #32798 now that the LLVM issues have been resolved.
> This adds the bitreverse intrinsic and adds a reverse_bits function to all integer types.
|
|
Fix spelling s/casted/cast/
r? @GuillaumeGomez
|
|
Slight modification to the as_ref example of std::option::Option
A user in a reddit thread was confused by the name of the variable
"num_as_int"; they thought the example was trying to convert the
string "10" as if it were binary 2 by calling str::len(). In reality,
the example is simply demonstrating how to take an immutable reference
to the value of an Option. The confusion comes from the coincidence
that the length of the string "10" is also its binary representation,
and the implication from the variable names that a conversion was
occuring ("num_as_str" to "num_as_int").
This PR changes the example number to 12 instead of 10, and changes
the variable name from "num_as_int" to "num_length" to better
communicate what the example is doing.
The reddit thread:
https://www.reddit.com/r/rust/comments/7zpvev/notyetawesome_rust_what_use_cases_would_you_like/dur39xw/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The error was:
```
[00:05:25] tidy error: /checkout/src/libcore/num/mod.rs:3848: trailing whitespace
[00:05:25] tidy error: /checkout/src/libcore/num/mod.rs:3851: line longer than 100 chars
[00:05:25] tidy error: /checkout/src/libcore/num/mod.rs:3851: trailing whitespace
[00:05:26] some tidy checks failed
```
The line was truncated to 92 characters.
|
|
Initially, I wanted to add it directly to the documentation of `str. parse()' method, I finally found that it was more relevant (I hope so?) to directly document the structure in question. I've added a scenario, in which we could all get caught at least once, to make it easier to diagnose the problem when parsing integers.
|
|
|
|
|
|
|
|
|
|
Rollup of 8 pull requests
- Successful merges: #48283, #48466, #48569, #48629, #48637, #48680, #48513, #48664
- Failed merges:
|
|
std: Add `arch` and `simd` modules
This commit imports the `stdsimd` crate into the standard library,
creating an `arch` and `simd` module inside of both libcore and libstd.
Both of these modules are **unstable** and will continue to be so until
RFC 2335 is stabilized.
As a brief recap, the modules are organized as so:
* `arch` contains all current architectures with intrinsics, for example
`std::arch::x86`, `std::arch::x86_64`, `std::arch::arm`, etc. These
modules contain all of the intrinsics defined for the platform, like
`_mm_set1_epi8`.
* In the standard library, the `arch` module also exports a
`is_target_feature_detected` macro which performs runtime detection to
determine whether a target feature is available at runtime.
* The `simd` module contains experimental versions of strongly-typed
lane-aware SIMD primitives, to be fully fleshed out in a future RFC.
The main purpose of this commit is to start pulling in all these
intrinsics and such into the standard library on nightly and allow
testing and such. This'll help allow users to easily kick the tires and
see if intrinsics work as well as allow us to test out all the
infrastructure for moving the intrinsics into the standard library.
|
|
Backport LLVM fixes for a JumpThreading / assume intrinsic bug
This fixes the original cause of #48116 and restores the assume intrinsic that was removed as a workaround.
r? @alexcrichton
|
|
|
|
FusedIterator is a marker trait that promises that the implementing
iterator continues to return `None` from `.next()` once it has returned
`None` once (and/or `.next_back()`, if implemented).
The effects of FusedIterator are already widely available through
`.fuse()`, but with stable `FusedIterator`, stable Rust users can
implement this trait for their iterators when appropriate.
|
|
Fixes #47311.
r? @nrc
|
|
Fixes #47311.
r? @nrc
|
|
Fixes #47311.
r? @nrc
|
|
also minor doc fixes.
Closes #43941
|
|
This commit imports the `stdsimd` crate into the standard library,
creating an `arch` and `simd` module inside of both libcore and libstd.
Both of these modules are **unstable** and will continue to be so until
RFC 2335 is stabilized.
As a brief recap, the modules are organized as so:
* `arch` contains all current architectures with intrinsics, for example
`std::arch::x86`, `std::arch::x86_64`, `std::arch::arm`, etc. These
modules contain all of the intrinsics defined for the platform, like
`_mm_set1_epi8`.
* In the standard library, the `arch` module also exports a
`is_target_feature_detected` macro which performs runtime detection to
determine whether a target feature is available at runtime.
* The `simd` module contains experimental versions of strongly-typed
lane-aware SIMD primitives, to be fully fleshed out in a future RFC.
The main purpose of this commit is to start pulling in all these
intrinsics and such into the standard library on nightly and allow
testing and such. This'll help allow users to easily kick the tires and
see if intrinsics work as well as allow us to test out all the
infrastructure for moving the intrinsics into the standard library.
|
|
|
|
|
|
|
