| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Document From trait for Option implementations
Add documentation for ```From``` trait for ```std::option::Option``` implementations
This PR solves a part of #51430 ( CC @skade )
This is my first PR ever in contributing for OSS. I'm happy to learn and make any changes if necessary :)
|
|
Be slightly more precise about any::type_name()'s guarantees.
The first commit in this PR rephrases the current documentation for `any::type_name()` to be a little more specific about the guarantees (or lack thereof) that this function makes. The second commit explicitly documents that lifetimes are currently not included in the output (since this bit me particularly hard recently).
|
|
Co-authored-by: Steve Klabnik <steve@steveklabnik.com>
|
|
Co-authored-by: Steve Klabnik <steve@steveklabnik.com>
|
|
Co-authored-by: Steve Klabnik <steve@steveklabnik.com>
|
|
Co-authored-by: Steve Klabnik <steve@steveklabnik.com>
|
|
Co-authored-by: Steve Klabnik <steve@steveklabnik.com>
|
|
Co-authored-by: Steve Klabnik <steve@steveklabnik.com>
|
|
Co-authored-by: Steve Klabnik <steve@steveklabnik.com>
|
|
Co-authored-by: Steve Klabnik <steve@steveklabnik.com>
|
|
|
|
Co-authored-by: Timo <timorcb@gmail.com>
|
|
|
|
Add core::future::{pending,ready}
Adds two future constructors to `core`: `future::ready` and `future::pending`. These functions enable constructing futures of any type that either immediately resolve, or never resolve which is an incredible useful tool when writing documentation.
These functions have prior art in both the `futures` and `async-std` crates. This implementation has been adapted from the `futures` crate.
## Examples
In https://github.com/rust-lang/rust/pull/70817 we propose adding the `ready!` macro. In the example we use an `async fn` which does not return a future that implements `Unpin`, which leads to the use of `unsafe`. Instead had we had `future::ready` available, we could've written the same example without using `unsafe`:
```rust
use core::task::{Context, Poll};
use core::future::{self, Future};
use core::pin::Pin;
pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> {
let mut fut = future::ready(42_u8);
let num = ready!(Pin::new(fut).poll(cx));
// ... use num
Poll::Ready(())
}
```
## Why future::ready?
Arguably `future::ready` and `async {}` can be considered equivalent. The main differences are that `future::ready` returns a future that implements `Unpin`, and the returned future is a concrete type. This is useful for traits that require a future as an associated type that can sometimes be a no-op ([example](https://docs.rs/http-service/0.4.0/http_service/trait.HttpService.html#associatedtype.ConnectionFuture)).
The final, minor argument is that `future::ready` and `future::pending` form a counterpart to the enum members of `Poll`: `Ready` and `Pending`. These functions form a conceptual bridge between `Poll` and `Future`, and can be used as a useful teaching device.
## References
- [`futures::future::ready`](https://docs.rs/futures/0.3.4/futures/future/fn.ready.html)
- [`futures::future::pending`](https://docs.rs/futures/0.3.4/futures/future/fn.pending.html)
- [`async_std::future::pending`](https://docs.rs/async-std/1.5.0/async_std/future/fn.pending.html)
- [`async_std::future::ready`](https://docs.rs/async-std/1.5.0/async_std/future/fn.ready.html)
|
|
|
|
|
|
Add comment for `Ord` implementation for array
Corresponding to `Ord` implementation for slice. It hints new comer the rule of comparing two arrays.
|
|
|
|
|
|
|
|
Add const examples
I only added them to `std::f32` to get feedback on this approach before adding the other constants.
When looking at https://github.com/rust-lang/rust/pull/68952, I found the docs a little confusing. Unless you're intimately aware of what's going on here, I don't think it's super clear what is deprecated and what you're supposed to do instead. I think short examples really clarify what's meant here, so that's what I did.
|
|
|
|
Use f64 in f64 examples
I believe that this is a copy/paste error; this example was using f32,
but it's the docs for f64.
|
|
|
|
I believe that this is a copy/paste error; this example was using f32,
but it's the docs for f64.
|
|
|
|
|
|
|
|
|
|
And also point people to use the associated constants of f32 instead.
|
|
|
|
This attempts to be a little clearer (including in terminology) about the lack
of guarantees that any::type_name provides.
|
|
Add `RefCell::take`
Add `RefCell::take` to match `Cell` and `Option`.
I also changed a couple of calls to `.replace` to `.take`.
Tracking issue is #71395.
This is my first contribution, please tell me if there's anything I could improve, thanks!
|
|
|
|
|
|
|
|
Rename Unique::empty() -> Unique::dangling()
A `FIXME` comment in `src/libcore/ptr/unique.rs` suggested refactoring `Unique::empty()` to `Unique::dangling()` which this PR does.
|
|
Add clarification on std::cfg macro docs v. #[cfg] attribute
The wording was discussed, to a limited degree in #71679. This tries to
address some confusion I as well as someone else had independently when
looking at this macro.
Fixes #71679
|
|
document missing stable counterparts of intrinsics
Notes the stable counterpart of each intrinsic in case one exists.
Implements #34338
r? @Dylan-DPC
|
|
rename-unique: Change calls and doc in raw_vec.rs
rename-unique: Change empty() -> dangling() in const-ptr-unique-rpass.rs
|
|
Co-Authored-By: kennytm <kennytm@gmail.com>
|
|
The wording was discussed, to a limited degree in #71679. This tries to
address some confusion I as well as someone else had independently when
looking at this macro.
Fixes #71679
|
|
Fix doc link to Eq trait from PartialEq trait
The `Eq` link was incorrectly going to the `eq` method of `PartialEq`
instead of to the `Eq` trait.
|
|
r=Mark-Simulacrum
Document unsafety in core::ptr
Contributes to #66219
I have yet to document all the `unsafe` blocks in the lib and would like to know if I'm headed in the right direction
r? @steveklabnik
|
|
The `Eq` link was incorrectly going to the `eq` method of `PartialEq`
instead of to the `Eq` trait.
|
|
|
|
Add documentation example to slice_from_raw_parts_mut()
Add SAFETY explanations to some unsafe blocks in libcore/ptr
* libcore/ptr/mod.rs
* libcore/ptr/unique.rs
* libcore/ptr/non_null.rs
safety-mod.rs: Add SAFETY to slice_from_raw_parts(),
slice_from_raw_parts_mut()
slice_from_raw_parts_mut: Add documentation example
safety-ptr-unique.rs: Add SAFETY to new() and cast()
safety-ptr-non_null.rs: Add SAFETY to new()
safety-ptr-non_null.rs: Add SAFETY to cast()
safety-ptr-non_null.rs: Add SAFETY to from() impls
safety-ptr-unique.rs: Add SAFETY to from() impls
safety-ptr-non_null.rs: Add SAFETY to new()
safety-ptr-unique.rs: Add SAFETY to new()
safety-ptr-mod.rs: Fix safety explanation
https://github.com/rust-lang/rust/pull/71507#discussion_r414488884
safety-prt-non_null.rs: Fix SAFETY comment syntax
safety-ptr-unique.rs: Fix syntax for empty()
safety-ptr-non_null.rs: Fix misuse of non-null for align_of()
safety-ptr-non_null.rs: Remove incorrect SAFETY comment
safety-ptr-unique.rs: Remove unsound SAFETY comment
safety-ptr-mod.rs: Add std comment on slice_from_raw_parts guarantee
safety-ptr-unique.rs: Remove incorrect safety comment
Creating a Unique from a NonNull has strict guarantees that the current
implementation does not guarantee
https://github.com/rust-lang/rust/pull/71507#discussion_r415035952
safety-ptr: Re-adding ignore-tidy directive
|
|
|
|
remove Unique::from for shared pointer types
r? @SimonSapin
|
|
|
