| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Prepare standard library for Rust 2024 migration
This includes a variety of commits preparing the standard library for migration to Rust 2024.
The actual migration is blocked on a few things, so I wanted to get this out of the way in a relatively digestable PR.
|
|
Stabilize `const_is_char_boundary` and `const_str_split_at`.
Tracking issues: #131516, #131518
Stabilized const API:
```rs
// in `core`
impl str {
// const_is_char_boundary feature
const fn is_char_boundary(&self, index: usize) -> bool;
// const_str_split_at feature, depends on const_is_char_boundary
const fn split_at(&self, mid: usize) -> (&str, &str);
const fn split_at_mut(&mut self, mid: usize) -> (&mut str, &mut str);
const fn split_at_checked(&self, mid: usize) -> Option<(&str, &str)>;
const fn split_at_mut_checked(&mut self, mid: usize) -> Option<(&mut str, &mut str)>;
}
```
This will allow safely splitting string slices during const-eval.
Closes #131516, Closes #131518
This will need FCP.
r? libs-api
IIUC these do not use any new const language features (i.e. they are implementable manually on stable 1.83.0 using `unsafe`: [playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=3679632cd1041084796241b7ac8edfbd)).
Cc ``@rust-lang/wg-const-eval`` (I don't know if I have the permissions for this ping; if not, someone else please ping wg-const-eval if it is necessary)
|
|
|
|
|
|
The 13.3 image is no longer provided by Google Cloud.
|
|
|
|
|
|
These functions were changed to be safe in
https://github.com/rust-lang/rust/pull/127763, but this particular UWP
version was missed. Otherwise this causes unnecessary unsafe block
warnings/errors.
|
|
|
|
|
|
|
|
|
|
alloc boxed: docs: use MaybeUninit::write instead of as_mut_ptr
In the deferred initialization pattern, the docs were needlessly going through `as_mut_ptr().write()` to initialize, which is unnecessary use of a pointer, needs to be inside an `unsafe` block, and may weaken alias analysis.
|
|
Use `slice::fill` in `io::Repeat` implementation
Use the existing `fill` methods on slices instead of manually writing the fill loop.
|
|
Remove the common prelude module
This fixes the issues described in https://github.com/rust-lang/rust/issues/136102. Primarily, this resolves some issues with how the documentation for the prelude is generated:
- It avoids showing "unstable" for macros in the prelude that are actually stable.
- Avoids duplication of some pages due to the previous lack of `doc(no_inline)`.
- Makes the different edition preludes consistent, and sets a pattern that can be used by future editions.
We may need to rearrange these modules in the future if we decide to remove anything from the prelude again. If we do, I think we should look into a different solution that avoids the documentation problems.
Closes https://github.com/rust-lang/rust/issues/136102
|
|
Correct comment for FreeBSD and DragonFly BSD in unix/thread
|
|
|
|
`transmute` should also assume non-null pointers
Previously it only did integer-ABI things, but this way it does data pointers too. That gives more information in general to the backend, and allows slightly simplifying one of the helpers in slice iterators.
|
|
Update backtrace
This updates the backtrace submodule.
6 commits in f8cc6ac9acc4e663ecd96f9bcf1ff4542636d1b9..9d2c34e7e63afe1e71c333b247065e3b7ba4d883
2025-01-04 03:37:47 +0100 to 2025-02-13 14:14:18 -0800
- Various cleanups: https://github.com/rust-lang/backtrace-rs/pull/673
- libunwind: Use builtin _Unwind_GetIP for NuttX on ARM platform: https://github.com/rust-lang/backtrace-rs/pull/692
- remove outdated docs part on Dbghelp::ensure_open: https://github.com/rust-lang/backtrace-rs/pull/696
- Cleanup Windows trace modules: https://github.com/rust-lang/backtrace-rs/pull/697
- Attempt to fix ARM32 Windows: https://github.com/rust-lang/backtrace-rs/pull/685
- Prepare backtrace for Rust 2024: https://github.com/rust-lang/backtrace-rs/pull/700
|
|
[AIX] expect `EINVAL` for `pthread_mutex_destroy`
Calling `pthread_mutex_destory` on a mutex initalized with the static initializer macro `PTHREAD_MUTEX_INITIALIZER` will result in `EINVAL` if the mutex is not lock/unlocked prior to calling `pthread_mutex_destroy`.
|
|
add `IntoBounds` trait
for `range_into_bounds` feature
Tracking issue: #136903
ACP: https://github.com/rust-lang/libs-team/issues/538
|
|
|
|
Also add
```rust
// #[unstable(feature = "float_gamma", issue = "99842")]
```
to `gamma`-function-related methods on `f16` & `f128`,
as per https://github.com/rust-lang/rust/pull/136324#issuecomment-2626270247
|
|
|
|
|
|
|
|
|
|
This generates a warning of irrefutable patterns. I decided to slightly
tweak the example so the closure returns unit, since the intent wasn't
to show the weird behavior of returning `!`.
|
|
|
|
|
|
|
|
|
|
A small workaround for https://github.com/rust-lang/rust/issues/136899,
rustdoc's invalid_rust_codeblocks was not handling this well in 2024.
This may be needed when migrating to 2024 when building with stage0.
|
|
|
|
Stabilize `get_many_mut` as `get_disjoint_mut`
Tracking issue: #104642
Closes #104642
FCP completed in https://github.com/rust-lang/rust/issues/104642#issuecomment-2558161073
|
|
|
|
|
|
In the deferred initialization pattern, the docs were needlessly going
through as_mut_ptr().write() to initialize, which is unnecessary use of
a pointer, needs to be inside an unsafe block, and may weaken alias
analysis.
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Use the existing `fill` methods on slices instead of manually
writing the fill loop.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fix import in bench for wasm
This import was causing annoying unused import errors when checking the standard library for some wasm targets. The problem is that everything here is disabled if it is wasm32, but this import wasn't cfg'd.
|
|
Use a trait to enforce field validity for union fields + `unsafe` fields + `unsafe<>` binder types
This PR introduces a new, internal-only trait called `BikeshedGuaranteedNoDrop`[^1] to faithfully model the field check that used to be implemented manually by `allowed_union_or_unsafe_field`.
https://github.com/rust-lang/rust/blob/942db6782f4a28c55b0b75b38fd4394d0483390f/compiler/rustc_hir_analysis/src/check/check.rs#L84-L115
Copying over the doc comment from the trait:
```rust
/// Marker trait for the types that are allowed in union fields, unsafe fields,
/// and unsafe binder types.
///
/// Implemented for:
/// * `&T`, `&mut T` for all `T`,
/// * `ManuallyDrop<T>` for all `T`,
/// * tuples and arrays whose elements implement `BikeshedGuaranteedNoDrop`,
/// * or otherwise, all types that are `Copy`.
///
/// Notably, this doesn't include all trivially-destructible types for semver
/// reasons.
///
/// Bikeshed name for now.
```
As far as I am aware, there's no new behavior being guaranteed by this trait, since it operates the same as the manually implemented check. We could easily rip out this trait and go back to using the manually implemented check for union fields, however using a trait means that this code can be shared by WF for `unsafe<>` binders too. See the last commit.
The only diagnostic changes are that this now fires false-negatives for fields that are ill-formed. I don't consider that to be much of a problem though.
r? oli-obk
[^1]: Please let's not bikeshed this name lol. There's no good name for `ValidForUnsafeFieldsUnsafeBindersAndUnionFields`.
|
