| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Stabilize Result::map_or_else
Stabilized this API:
```rust
impl<T, E> Result<T, E> {
pub fn map_or_else<U, D: FnOnce(E) -> U, F: FnOnce(T) -> U>(self, default: D, f: F) -> U {
match self {
Ok(t) => f(t),
Err(e) => default(e),
}
}
}
```
Closes #53268
r? @SimonSapin
|
|
make `./x.py bench` again
Fixes #54016
|
|
mem::forget docs: mention ManuallyDrop
Cc @SimonSapin @Centril
|
|
|
|
Clarify Step Documentation
While the redesign is in progress (#62886), clarify the purpose of replace_zero and replace_one.
First, "returning itself" is technically impossible due to the function signature of &mut self -> Self. A clone or copy operation must be used. So this is now explicitly stated in the documentation.
Second, the added docs give some guidance about the actual contract around implementation of replace_zero and replace one. Specifically, the only usage is to create a range with no more steps, by setting start to replace_one and end to replace_zero. So the only property that is actually used is `replace_one > replace_zero`. See https://github.com/rust-lang/rust/issues/42168#issuecomment-489554232
The new documentation does not say that is the *only* contract, and so it should not be considered an api change. It just highlights the most important detail for implementors.
The redesign doesn't seem to be landing any time soon, so this is a stopgap measure to reduce confusion in the meantime.
|
|
add fn type_name_of_val
This function is often useful during testing and mirrors `align_of_val` and `size_of_val`.
# Example
Showing the default type of integers.
```rust
let x = 7;
println!("per default, integers have the type: {}", std::any::type_name_of_val(&x));
```
To my knowledge this can currently not be done without defining a function similar to `type_name_of_val`.
|
|
follow the convention in this file to use third-person singular verbs
|
|
Document pitfall with `impl PartialEq<B> for A`
Fixes #66476 by turning the violating example into an explicit
counterexample.
|
|
|
|
Fixes #66476 by turning the violating example into an explicit
counterexample.
|
|
|
|
|
|
While the redesign is in progress (#62886), clarify the purpose of replace_zero and replace_one.
|
|
|
|
This skips the loop when the element type is known not to have drop glue, even in debug mode.
|
|
Suggest borrowing when it would satisfy an unmet trait bound
When there are multiple implementors for the same trait that is present
in an unmet binding, modify the E0277 error to refer to the parent
obligation and verify whether borrowing the argument being passed in
would satisfy the unmet bound. If it would, suggest it.
Fix #56368.
|
|
Clarify transmute_copy documentation example
Currently the documentation for `transmute_copy` implies that the function accepts a slice due to the variable name chosen in the example. This is misleading as `foo_slice` is actually an array and `transmute_copy` cannot take an unsized type anyway.
This PR just clarifies things by renaming the variable used in the example.
|
|
When there are multiple implementors for the same trait that is present
in an unmet binding, modify the E0277 error to refer to the parent
obligation and verify whether borrowing the argument being passed in
would satisfy the unmet bound. If it would, suggest it.
|
|
|
|
|
|
|
|
add Result::map_or
This PR adds this API to make it consistent with `Option::map_or`.
```rust
impl<T, E> Result<T, E> {
pub fn map_or<U, F: FnOnce(T) -> U>(self, default: U, f: F) -> U {
match self {
Ok(t) => f(t),
Err(_) => default,
}
}
}
```
This API is very small. We already has a similar API for `Option::map_or`.
|
|
add raw ptr variant of UnsafeCell::get
This has come up recently in https://github.com/rust-lang/rust/pull/66051 (Cc @Centril @pitdicker) as well as in discussion with @nikomatsakis and in unrelated discussion with @withoutboats.
|
|
Fix documentation for `Iterator::count()`.
The documentation of std::core::Iterator::count() stated that the number returned is the number of times `next` is called on the iterator. However this is not true as the number of times `next` is called is exactly one plus the number returned by `count()`.
|
|
|
|
|
|
|
|
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
|
|
Stage0 step
r? @pietroalbini
|
|
|
|
Add hooks for Miri panic unwinding
This commits adds in some additional hooks to allow Miri to properly
handle panic unwinding. None of this should have any impact on CTFE mode
This supports https://github.com/rust-lang/miri/pull/693
|
|
remove vestigial comments referring to defunct numeric trait hierarchy
I've been poking around the numeric trait hierarchy and also some of the actual numeric type implementations.
This is a small change but a matter of effective communication. I looked for other related references and saw none.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
invalid_value lint: use diagnostic items
This adjusts the invalid_value lint to use diagnostic items.
@Centril @oli-obk For some reason, this fails to recognize `transmute` -- somehow the diagnostic item is not found. Any idea why?
r? @Centril
Cc https://github.com/rust-lang/rust/issues/66075
|
|
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #65949 (Move promotion into its own pass)
- #65994 (Point at where clauses where the associated item was restricted)
- #66050 (Fix C aggregate-passing ABI on powerpc)
- #66134 (Point at formatting descriptor string when it is invalid)
- #66172 (Stabilize @file command line arguments)
- #66226 (add link to unstable book for asm! macro)
Failed merges:
r? @ghost
|
|
r=nikomatsakis
Stabilize the `re_rebalance_coherence` feature
This PR stabilizes [RFC 2451](https://rust-lang.github.io/rfcs/2451-re-rebalancing-coherence.html), re-rebalance coherence.
Changes include removing the attribute from tests which tested both the old and new behavior, moving the feature to `accepted` and removing the old logic.
I'll also open a [PR](https://github.com/rust-lang-nursery/reference/pull/703) against the reference, updating it with the content of the RFC.
Closes #63599
r? @nikomatsakis
|
|
see also https://github.com/rust-lang/rust/pull/23104/files
|
|
|
|
Add `MaybeUninit` methods `uninit_array`, `slice_get_ref`, `slice_get_mut`
Eventually these will hopefully become the idiomatic way to work with partially-initialized stack buffers.
All methods are unstable. Note that `uninit_array` takes a type-level `const usize` parameter, so it is blocked (at least in its current form) on const generics.
Example:
```rust
use std::mem::MaybeUninit;
let input = b"Foo";
let f = u8::to_ascii_uppercase;
let mut buffer: [MaybeUninit<u8>; 32] = MaybeUninit::uninit_array();
let vec;
let output = if let Some(buffer) = buffer.get_mut(..input.len()) {
buffer.iter_mut().zip(input).for_each(|(a, b)| { a.write(f(b)); });
unsafe { MaybeUninit::slice_get_ref(buffer) }
} else {
vec = input.iter().map(f).collect::<Vec<u8>>();
&vec
};
assert_eq!(output, b"FOO");
```
|
|
Have tidy ensure that we document all `unsafe` blocks in libcore
cc @rust-lang/libs
I documented a few and added ignore flags on the other files. We can incrementally document the files, but won't regress any files this way.
|
|
|
|
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
|
