Remove `&mut` from `io::read_to_string` signature
``@m-ou-se`` [realized][1] that because `Read` is implemented for `&mut impl
Read`, there's no need to take `&mut` in `io::read_to_string`.
Removing the `&mut` from the signature allows users to remove the `&mut`
from their calls (and thus pass an owned reader) if they don't use the
reader later.
r? `@m-ou-se`
[1]: https://github.com/rust-lang/rust/issues/80218#issuecomment-874322129
Inline std::os::unix::ffi::OsStringExt methods
Those methods essentially do nothing at assembly level. On Unix systems, `OsString` is represented as a `Vec` without performing any transformations.
Simplification of BigNum::bit_length
As indicated in the comment, the BigNum::bit_length function could be
optimized by using CLZ, which is often a single instruction instead a
loop.
I think the code is also simpler now without the loop.
I added some additional tests for Big8x3 and Big32x40 to ensure that
there were no regressions.
Extend const_convert to rest of blanket core::convert impls
This adds constness to all the blanket impls in `core::convert` under the existing `const_convert` feature, tracked by #88674.
Existing impls under that feature:
```rust
impl<T> const From<T> for T;
impl<T, U> const Into<U> for T where U: ~const From<T>;
impl<T> const ops::Try for Option<T>;
impl<T> const ops::FromResidual for Option<T>;
impl<T, E> const ops::Try for Result<T, E>;
impl<T, E, F> const ops::FromResidual<Result<convert::Infallible, E>> for Result<T, F> where F: ~const From<E>;
```
Additional impls:
```rust
impl<T: ?Sized, U: ?Sized> const AsRef<U> for &T where T: ~const AsRef<U>;
impl<T: ?Sized, U: ?Sized> const AsRef<U> for &mut T where T: ~const AsRef<U>;
impl<T: ?Sized, U: ?Sized> const AsMut<U> for &mut T where T: ~const AsMut<U>;
impl<T, U> const TryInto<U> for T where U: ~const TryFrom<T>;
impl<T, U> const TryFrom<U> for T where U: ~const Into<T>;
```
Partially stabilize `maybe_uninit_extra`
This covers:
```rust
impl<T> MaybeUninit<T> {
pub unsafe fn assume_init_read(&self) -> T { ... }
pub unsafe fn assume_init_drop(&mut self) { ... }
}
```
It does not cover the const-ness of `write` under `const_maybe_uninit_write` nor the const-ness of `assume_init_read` (this commit adds `const_maybe_uninit_assume_init_read` for that).
FCP: https://github.com/rust-lang/rust/issues/63567#issuecomment-958590287.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
`@m-ou-se` [realized][1] that because `Read` is implemented for `&mut impl
Read`, there's no need to take `&mut` in `io::read_to_string`.
Removing the `&mut` from the signature allows users to remove the `&mut`
from their calls (and thus pass an owned reader) if they don't use the
reader later.
[1]: https://github.com/rust-lang/rust/issues/80218#issuecomment-874322129
Add `std::error::Report` type
This is a continuation of https://github.com/rust-lang/rust/pull/90174, split into a separate PR since I cannot push to ```````@seanchen1991``````` 's fork
Simpilfy thread::JoinInner.
`JoinInner`'s `native` field was an `Option`, but that's unnecessary.
Also, thanks to `Arc::get_mut`, there's no unsafety needed in `JoinInner::join()`.
Eliminate "boxed" wording in `std::error::Error` documentation
In commit 29403ee, documentation for the methods on `std::any::Any` was
modified so that they referred to the concrete value behind the trait
object as the "inner" value. This is a more accurate wording than
"boxed": while putting trait objects inside boxes is arguably the most
common use, they can also be placed behind other pointer types like
`&mut` or `std::sync::Arc`.
This commit does the same documentation changes for `std::error::Error`.
Improve documentation for File::options to give a more likely example
`File::options().read(true).open(...)` is equivalent to just
`File::open`. Change the example to set the `append` flag instead, and
then change the filename to something more likely to be written in
append mode.
This covers:
impl<T> MaybeUninit<T> {
pub unsafe fn assume_init_read(&self) -> T { ... }
pub unsafe fn assume_init_drop(&mut self) { ... }
}
It does not cover the const-ness of `write` under
`const_maybe_uninit_write` nor the const-ness of
`assume_init_read` (this commit adds
`const_maybe_uninit_assume_init_read` for that).
FCP: https://github.com/rust-lang/rust/issues/63567#issuecomment-958590287.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Replace usages of vec![].into_iter with [].into_iter
`[].into_iter` is idiomatic over `vec![].into_iter` because its simpler and faster (unless the vec is optimized away in which case it would be the same)
So we should change all the implementation, documentation and tests to use it.
I skipped:
* `src/tools` - Those are copied in from upstream
* `src/test/ui` - Hard to tell if `vec![].into_iter` was used intentionally or not here and not much benefit to changing it.
* any case where `vec![].into_iter` was used because we specifically needed a `Vec::IntoIter<T>`
* any case where it looked like we were intentionally using `vec![].into_iter` to test it.
`File::options().read(true).open(...)` is equivalent to just
`File::open`. Change the example to set the `append` flag instead, and
then change the filename to something more likely to be written in
append mode.
In commit 29403ee, documentation for the methods on `std::any::Any` was
modified so that they referred to the concrete value behind the trait
object as the "inner" value. This is a more accurate wording than
"boxed": while putting trait objects inside boxes is arguably the most
common use, they can also be placed behind other pointer types like
`&mut` or `std::sync::Arc`.
This commit does the same documentation changes for `std::error::Error`.
As indicated in the comment, the BigNum::bit_length function could be
optimized by using CLZ, which is often a single instruction instead a
loop.
I think the code is also simpler now without the loop.
I added some additional tests for Big8x3 and Big32x40 to ensure that
there were no regressions.
Mak DefId to AccessLevel map in resolve for export
hir_id to accesslevel in resolve and applied in privacy
using local def id
removing tracing probes
making function not recursive and adding comments
Move most of Exported/Public res to rustc_resolve
moving public/export res to resolve
fix missing stability attributes in core, std and alloc
move code to access_levels.rs
return for some kinds instead of going through them
Export correctness, macro changes, comments
add comment for import binding
add comment for import binding
renmae to access level visitor, remove comments, move fn as closure, remove new_key
fmt
fix rebase
fix rebase
fmt
fmt
fix: move macro def to rustc_resolve
fix: reachable AccessLevel for enum variants
fmt
fix: missing stability attributes for other architectures
allow unreachable pub in rustfmt
fix: missing impl access level + renaming export to reexport
Missing impl access level was found thanks to a test in clippy
Make `Atomic*::from_mut` return `&mut Atomic*`
```rust
impl Atomic* {
pub fn from_mut(v: &mut bool) -> &mut Self;
// ^^^^---- previously was just a &
}
```
This PR makes `from_mut` atomic methods tracked in #76314 return unique references to atomic types, instead of shared ones. This makes `from_mut` and `get_mut` inverses of each other, allowing to undo either of them by the other.
r? `@RalfJung`
(as Ralf was [concerned](https://github.com/rust-lang/rust/issues/76314#issuecomment-955062593) about this)
Implemented const casts of raw pointers
This adds `as_mut()` method for `*const T` and `as_const()` for `*mut T`
which are intended to make casting of consts safer. This was discussed
in the [internals discussion][discussion].
Given that this is a simple change and multiple people agreed to it including `@RalfJung` I decided to go ahead and open the PR.
[discussion]: https://internals.rust-lang.org/t/casting-constness-can-be-risky-heres-a-simple-fix/15933
Add some missing `#[must_use]` to some `f{32,64}` operations
This PR adds `#[must_use]` to the following methods:
- `f32::recip`
- `f32::max`
- `f32::min`
- `f32::maximum`
- `f32::minimum`
and their equivalents in `f64`.
These methods all produce a new value without modifying the original and so are pointless to call without using the result.
Add note about non_exhaustive to variant_count
Since `variant_count` isn't returning something opaque, I thought it makes sense to explicitly call out that its return value may change for some enums.
cc #73662
Previously suggested in https://github.com/rust-lang/rfcs/issues/2854.
It makes sense to have this since `char` implements `From<u8>`. Likewise
`u32`, `u64`, and `u128` (since #79502) implement `From<char>`.
Rollup of 7 pull requests
Successful merges:
- #92092 (Drop guards in slice sorting derive src pointers from &mut T, which is invalidated by interior mutation in comparison)
- #92388 (Fix a minor mistake in `String::try_reserve_exact` examples)
- #92442 (Add negative `impl` for `Ord`, `PartialOrd` on `LocalDefId`)
- #92483 (Stabilize `result_cloned` and `result_copied`)
- #92574 (Add RISC-V detection macro and more architecture instructions)
- #92575 (ast: Always keep a `NodeId` in `ast::Crate`)
- #92583 (⬆️ rust-analyzer)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Add RISC-V detection macro and more architecture instructions
This pull request includes:
- Update `stdarch` dependency to include ratified RISC-V supervisor and hypervisor instruction intrinsics which is useful in Rust kernel development
- Add macro `is_riscv_feature_detected!`
- Modify impl of `core::hint::spin_loop` to comply with latest version of `core::arch`
After this update, users may now develop RISC-V kernels and user applications more freely.
r? `@Amanieu`
Fix a minor mistake in `String::try_reserve_exact` examples
The examples of `String::try_reserve_exact` didn't actually use `try_reserve_exact`, which was probably a minor mistake, and this PR fixed it.
Drop guards in slice sorting derive src pointers from &mut T, which is invalidated by interior mutation in comparison
I tried to run https://github.com/rust-lang/miri-test-libstd on `alloc` with `-Zmiri-track-raw-pointers`, and got a failure on the test `slice::panic_safe`. The test failure has nothing to do with panic safety, it's from how the test tests for panic safety.
I minimized the test failure into this very silly program:
```rust
use std::cell::Cell;
use std::cmp::Ordering;
#[derive(Clone)]
struct Evil(Cell<usize>);
fn main() {
let mut input = vec![Evil(Cell::new(0)); 3];
// Hits the bug pattern via CopyOnDrop in core
input.sort_unstable_by(|a, _b| {
a.0.set(0);
Ordering::Less
});
// Hits the bug pattern via InsertionHole in alloc
input.sort_by(|_a, b| {
b.0.set(0);
Ordering::Less
});
}
```
To fix this, I'm just removing the mutability/uniqueness where it wasn't required.
Matthias Krüger