| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This reverts commit 8ed2292dbe75b9b65e9fe1a079428d1e1e3b610f.
It caused doctests in this repository to no longer be tested including all of the core crate.
|
|
|
|
DoubleEndedIterators."
This reverts commit 3e86cf36b5114f201868bf459934fe346a76a2d4.
|
|
|
|
remove confusing remarks about mixed volatile and non-volatile accesses
These comments were originally added by @ecstatic-morse in https://github.com/rust-lang/rust/commit/911d35f0bfd207112806eaec2763201dad06d1c7 and then later edited by me. The intention, I think, was to make sure people do both their reads and writes with these methods if the affected memory really is used for communication with external devices.
However, [people read this as saying that mixed volatile/non-volatile accesses are UB](https://github.com/rust-lang/rust/issues/58599#issuecomment-493791130), which -- to my knowledge -- they are not. So better remove this.
Cc @rkruppe @rust-lang/wg-unsafe-code-guidelines
|
|
Fix intra-doc link resolution failure on re-exporting libstd
Currently, re-exporting libstd items as below will [occur a lot of failures](https://gist.github.com/taiki-e/e33e0e8631ef47f65a74a3b69f456366).
```rust
pub use std::*;
```
Until the underlying issue (#56922) fixed, we can fix that so they don't propagate to downstream crates.
Related: https://github.com/rust-lang/rust/pull/56941 (That PR fixed failures that occur when re-exporting from libcore to libstd.)
r? @QuietMisdreavus
|
|
|
|
|
|
|
|
|
|
future
Also expand the documentation a bit
|
|
|
|
Fix the data types indication in basic examples of the Trait std::fmt::LowerExp and std::fmt::UpperExp.
Since there aren’t any type annotation on the let statement using the number 42.0, they are of type f64 according to The Book:
https://doc.rust-lang.org/book/ch03-02-data-types.html#floating-point-types
|
|
Fix typos in docs of GlobalAlloc
|
|
fix copy-paste typo in docs for ptr::read_volatile
|
|
Use iter() for iterating arrays by slice
These `into_iter()` calls will change from iterating references to
values if we ever get `IntoIterator` for arrays, which may break the
code using that iterator. Calling `iter()` is future proof.
|
|
Mark core::alloc::Layout::from_size_align_unchecked const
Makes it possible (pending stabilization of #57563 (`const_fn`)) to rewrite code like
```rust
const BUFFER_SIZE: usize = 0x2000;
const BUFFER_ALIGN: usize = 0x1000;
fn foo() {
let layout = std::alloc::Layout::from_size_align(BUFFER_SIZE, BUFFER_ALIGN)
.unwrap();
let buffer = std::alloc::alloc(layout);
}
```
to
```rust
const BUFFER_LAYOUT: std::alloc::Layout = unsafe {
std::alloc::Layout::from_size_align_unchecked(0x2000, 0x1000)
};
fn foo() {
let buffer = std::alloc::alloc(BUFFER_LAYOUT);
}
```
which (although `unsafe` is used) looks somewhat cleaner and is easier to read.
|
|
|
|
|
|
These `into_iter()` calls will change from iterating references to
values if we ever get `IntoIterator` for arrays, which may break the
code using that iterator. Calling `iter()` is future proof.
|
|
Fix convert module's documentation links
r? @steveklabnik
|
|
Improve the "must use" lint for `Future`
Fixes #60797
|
|
as_ptr returns a read-only pointer
Add comments to `as_ptr` methods to warn that these are read-only pointers, and writing to them is UB.
[It was pointed out](https://internals.rust-lang.org/t/as-ptr-vs-as-mut-ptr/9940) that `CStr` does not even have an `as_mut_ptr`. I originally was going to add one, but there is no method at all that would mutate a `CStr`. Was that a deliberate choice or should I add an `as_mut_ptr` (similar to [what I did for `str`](https://github.com/rust-lang/rust/pull/58200))?
|
|
Add implementations of last in terms of next_back on a bunch of DoubleEndedIterators
Provided a `DoubleEndedIterator` has finite length, `Iterator::last` is equivalent to `DoubleEndedIterator::next_back`. But searching forwards through the iterator when it's unnecessary is obviously not good for performance. I ran into this on one of the collection iterators.
I tried adding appropriate overloads for a bunch of the iterator adapters like filter, map, etc, but I ran into a lot of type inference failures after doing so.
The other interesting case is what to do with `Repeat`. Do we consider it part of the contract that `Iterator::last` will loop forever on it? The docs do say that the iterator will be evaluated until it returns None. This is also relevant for the adapters, it's trivially easy to observe whether a `Map` adapter invoked its closure a zillion times or just once for the last element.
|
|
|
|
|
|
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
|
|
coretest: Downgrade deny to warn
The `deny` causes a build failure in https://github.com/RalfJung/miri-test-libstd. Since we use `-D warnings` for rustc builds, `warn` should be enough to lead to compile errors here, without impeding external builds.
|
|
const-stabilize NonNull::dangling and NonNull::cast
|
|
impl From<Infallible> for TryFromSliceError
I believe this was missed when TryFrom was stabilized. I think `TryFromSliceError` and `TryFromIntError` are the only two `TryFrom` error types that appear in `std`. I think trait implementations have to be insta-stable, but I'm not sure.
|
|
Revert "Disable big-endian simd in swap_nonoverlapping_bytes"
This reverts commit 77bd4dc65406ba3cedbc779e6f6280868231912e (#43159).
Issue #42778 was formerly easy to reproduce on two big-endian targets,
`powerpc64` and `s390x`, so we disabled SIMD on this function for all
big-endian targets as a workaround.
I have re-tested this code on `powerpc64` and `s390x`, each with the
bundled LLVM 8 and with external LLVM 7 and LLVM 6, and the problems no
longer appear. So it seems safe to remove this workaround, although I'm
still a little uncomfortable that we never found a root-cause...
Closes #42778.
r? @arielb1
|
|
Stabilize and re-export core::array in std
Fixes #60014
|
|
pin: make the to-module link more visible
Cc @gnzlbg
|
|
Add a `cast` method to raw pointers.
This is similar to `NonNull::cast`.
Compared to the `as` operator (which has a wide range of meanings depending on the input and output types), a call to this method:
* Can only go from a raw pointer to a raw pointer
* Cannot change the pointer’s `const`ness
… even when the pointed types are inferred based on context.
|
|
|
|
to_xe_bytes for isize and usize returns an array of different size
... on different platforms.
Official rustdoc of
[`usize::to_le_bytes`](https://doc.rust-lang.org/std/primitive.usize.html#method.to_le_bytes)
displays signature
```
pub fn to_ne_bytes(self) -> [u8; 8]
```
which might be misleading: this function returns 4 bytes on 32-bit
systems.
With this commit applied rustdoc for `isize` and `usize` is this:
<img width="740" alt="2019-04-15_0020" src="https://user-images.githubusercontent.com/28969/56100765-9f69b380-5f14-11e9-974c-daa25edaa881.png">
|
|
|
|
Be a bit more explicit asserting over the vec rather than the len
|
|
|
|
This is similar to `NonNull::cast`.
Compared to the `as` operator (which has a wide range of meanings
depending on the input and output types), a call to this method:
* Can only go from a raw pointer to a raw pointer
* Cannot change the pointer’s `const`ness
… even when the pointed types are inferred based on context.
|
|
This reverts commit 77bd4dc65406ba3cedbc779e6f6280868231912e.
Issue #42778 was formerly easy to reproduce on two big-endian targets,
`powerpc64` and `s390x`, so we disabled SIMD on this function for all
big-endian targets as a workaround.
I have re-tested this code on `powerpc64` and `s390x`, each with the
bundled LLVM 8 and with external LLVM 7 and LLVM 6, and the problems no
longer appear. So it seems safe to remove this workaround, although I'm
still a little uncomfortable that we never found a root-cause...
|
|
... on different platforms.
Official rustdoc of
[`usize::to_le_bytes`](https://doc.rust-lang.org/std/primitive.usize.html#method.to_le_bytes)
displays signature
```
pub fn to_ne_bytes(self) -> [u8; 8]
```
which might be misleading: this function returns 4 bytes on 32-bit
systems.
|
|
|
|
|
|
|
|
Stabilize str::as_mut_ptr
Closes #58215
|
|
Option::flatten
This PR makes this possible.
```rust
assert_eq!(Some(6), Some(Some(6)).flatten());
assert_eq!(Some(6), Some(Some(6)).into());
```
|
|
Fix equivalent string in escape_default docs
This newline should be escaped.
|
|
|
|
const-stabilize: std::mem::needs_drop
Closes #51929
r? @oli-obk
|
