| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Revert "Add implementations of last in terms of next_back on a bunch of DoubleEndedIterators."
This changed observable behavior for several iterator types.
r? @alexcrichton
|
|
DoubleEndedIterators."
This reverts commit 3e86cf36b5114f201868bf459934fe346a76a2d4.
|
|
|
|
|
|
Signed-off-by: wizAmit <amitforfriends_dns@yahoo.com>
|
|
Signed-off-by: wizAmit <amitforfriends_dns@yahoo.com>
|
|
Signed-off-by: wizAmit <amitforfriends_dns@yahoo.com>
|
|
Simplify RefCell minimum_spanning_tree example
This simplifies the implementation of the `minimum_spanning_tree` example of `RefCell` in the `cell` module-level docs, avoiding an unnecessary recursive call. This also eliminates the need for a block to contain the scope of the borrow in this example. But since that use of a block served an important didactic purpose, we make up for this by instead introducing a block in the initial, simpler example of `RefCell`, where the point will hopefully be conveyed to the reader more easily.
|
|
is FFI safe
This allows types like Option<NonZeroU8> to be used in FFI without triggering the improper_ctypes lint. This works by changing the is_repr_nullable_ptr function to consider an enum E to be FFI-safe if:
- E has no explicit #[repr(...)].
- It only has two variants.
- One of those variants is empty (meaning it has no fields).
- The other variant has only one field.
- That field is one of the following:
- &T
- &mut T
- extern "C" fn
- core::num::NonZero*
- core::ptr::NonNull<T>
- #[repr(transparent)] struct wrapper around one of the types in this list.
- The size of E and its field are both known and are both the same size (implying E is participating in the nonnull optimization).
|
|
|
|
|
|
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
|
|
Servo has been using this since https://github.com/servo/servo/pull/23196 to add a runtime check to some unsafe code, as discussed in PR https://github.com/rust-lang/rust/pull/59211. Stabilizing would help do more of the same in libraries that also have users on Stable.
|
|
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.
|
|
|
|
|
|
|
|
Signed-off-by: wizAmit <amitforfriends_dns@yahoo.com>
|
|
Signed-off-by: wizAmit <amitforfriends_dns@yahoo.com>
|
|
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">
|
|
|
