Update subtree/library to 2025-03-02 #8
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
This fixes the issues described in rust-lang#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.
This reverts commit 685f189.
This feature is intended to provide expensive but thorough help for developers who have an unexpected `TypeId` value and need to determine what type it actually is. It causes `impl Debug for TypeId` to print the type name in addition to the opaque ID hash, and in order to do so, adds a name field to `TypeId`. The cost of this is the increased size of `TypeId` and the need to store type names in the binary; therefore, it is an optional feature. It may be enabled via `cargo -Zbuild-std -Zbuild-std-features=debug_typeid`. (Note that `-Zbuild-std-features` disables default features which you may wish to reenable in addition; see <https://doc.rust-lang.org/cargo/reference/unstable.html#build-std-features>.) Example usage and output: ``` fn main() { use std::any::{Any, TypeId}; dbg!(TypeId::of::<usize>(), drop::<usize>.type_id()); } ``` ``` TypeId::of::<usize>() = TypeId(0x763d199bccd319899208909ed1a860c6 = usize) drop::<usize>.type_id() = TypeId(0xe6a34bd13f8c92dd47806da07b8cca9a = core::mem::drop<usize>) ``` Also added feature declarations for the existing `debug_refcell` feature so it is usable from the `rust.std-features` option of `config.toml`.
And leave a comment on the unusual `cfg_attr` Co-authored-by: waffle <[email protected]>
… r=jhpratt Change the issue number for `likely_unlikely` and `cold_path` These currently point to rust-lang#26179, which is nearly a decade old and has a lot of outdated discussion. Move these features to a new tracking issue specifically for the recently added API. New tracking issue: rust-lang#136873
…r=WaffleLapkin Revert "Stabilize `extended_varargs_abi_support`" I cannot find an FCP for this, despite it being a stabilization PR which normally means we do an FCP of some kind? It would seem reasonable for _either_ compiler or lang to have FCPed it? I am thus opening a revert PR, which mostly-cleanly applies, so that we can later actually land this properly with a stability report and FCP. - rust-lang#136896 - rust-lang#116161 - rust-lang#100189
Rustc dev guide subtree update r? ``@ghost``
…jubilee documentation fix: `f16` and `f128` are not double-precision
…llaumeGomez Rollup of 8 pull requests Successful merges: - rust-lang#134981 ( Explain that in paths generics can't be set on both the enum and the variant) - rust-lang#136698 (Replace i686-unknown-redox target with i586-unknown-redox) - rust-lang#136767 (improve host/cross target checking) - rust-lang#136829 ([rustdoc] Move line numbers into the `<code>` directly) - rust-lang#136875 (Rustc dev guide subtree update) - rust-lang#136900 (compiler: replace `ExternAbi::name` calls with formatters) - rust-lang#136913 (Put kobzol back on review rotation) - rust-lang#136915 (documentation fix: `f16` and `f128` are not double-precision) r? `@ghost` `@rustbot` modify labels: rollup
The `#[must_use]` attribute has no effect when applied to methods in trait implementations.
…e conversion functions Having these implementation available crate-wide means that platforms not using sockets for their networking code have to stub out the libc definitions required to support them. This PR moves the conversions to private helper functions that are only available where actually needed. I also fixed the signature of the function converting from a C socket address to a Rust one: taking a reference to a `sockaddr_storage` resulted in unsound usage inside `LookupHost::next`, which could create a reference to a structure smaller than `sockaddr_storage`. Thus I've replaced the argument type with a pointer and made the function `unsafe`.
…lfJung Change swap_nonoverlapping from lang to library UB The implementation of ptr::swap_nonoverlapping does not always escalate its safety contract to language UB, so it should be `check_library_ub`. Fixes rust-lang/miri#4188
This will be used in Clippy to detect unbuffered calls to `Read::bytes()`.
for `range_into_bounds` feature, rust-lang#136903
Stabilize target_feature_11 # Stabilization report This is an updated version of rust-lang#116114, which is itself a redo of rust-lang#99767. Most of this commit and report were copied from those PRs. Thanks ```@LeSeulArtichaut``` and ```@calebzulawski!``` ## Summary Allows for safe functions to be marked with `#[target_feature]` attributes. Functions marked with `#[target_feature]` are generally considered as unsafe functions: they are unsafe to call, cannot *generally* be assigned to safe function pointers, and don't implement the `Fn*` traits. However, calling them from other `#[target_feature]` functions with a superset of features is safe. ```rust // Demonstration function #[target_feature(enable = "avx2")] fn avx2() {} fn foo() { // Calling `avx2` here is unsafe, as we must ensure // that AVX is available first. unsafe { avx2(); } } #[target_feature(enable = "avx2")] fn bar() { // Calling `avx2` here is safe. avx2(); } ``` Moreover, once rust-lang#135504 is merged, they can be converted to safe function pointers in a context in which calling them is safe: ```rust // Demonstration function #[target_feature(enable = "avx2")] fn avx2() {} fn foo() -> fn() { // Converting `avx2` to fn() is a compilation error here. avx2 } #[target_feature(enable = "avx2")] fn bar() -> fn() { // `avx2` coerces to fn() here avx2 } ``` See the section "Closures" below for justification of this behaviour. ## Test cases Tests for this feature can be found in [`tests/ui/target_feature/`](https://github.com/rust-lang/rust/tree/f6cb952dc115fd1311b02b694933e31d8dc8b002/tests/ui/target-feature). ## Edge cases ### Closures * [target-feature 1.1: should closures inherit target-feature annotations? rust-lang#73631](rust-lang#73631) Closures defined inside functions marked with #[target_feature] inherit the target features of their parent function. They can still be assigned to safe function pointers and implement the appropriate `Fn*` traits. ```rust #[target_feature(enable = "avx2")] fn qux() { let my_closure = || avx2(); // this call to `avx2` is safe let f: fn() = my_closure; } ``` This means that in order to call a function with #[target_feature], you must guarantee that the target-feature is available while the function, any closures defined inside it, as well as any safe function pointers obtained from target-feature functions inside it, execute. This is usually ensured because target features are assumed to never disappear, and: - on any unsafe call to a `#[target_feature]` function, presence of the target feature is guaranteed by the programmer through the safety requirements of the unsafe call. - on any safe call, this is guaranteed recursively by the caller. If you work in an environment where target features can be disabled, it is your responsibility to ensure that no code inside a target feature function (including inside a closure) runs after this (until the feature is enabled again). **Note:** this has an effect on existing code, as nowadays closures do not inherit features from the enclosing function, and thus this strengthens a safety requirement. It was originally proposed in rust-lang#73631 to solve this by adding a new type of UB: “taking a target feature away from your process after having run code that uses that target feature is UB” . This was motivated by userspace code already assuming in a few places that CPU features never disappear from a program during execution (see i.e. https://github.com/rust-lang/stdarch/blob/2e29bdf90832931ea499755bb4ad7a6b0809295a/crates/std_detect/src/detect/arch/x86.rs); however, concerns were raised in the context of the Linux kernel; thus, we propose to relax that requirement to "causing the set of usable features to be reduced is unsafe; when doing so, the programmer is required to ensure that no closures or safe fn pointers that use removed features are still in scope". * [Fix #[inline(always)] on closures with target feature 1.1 rust-lang#111836](rust-lang#111836) Closures accept `#[inline(always)]`, even within functions marked with `#[target_feature]`. Since these attributes conflict, `#[inline(always)]` wins out to maintain compatibility. ### ABI concerns * [The extern "C" ABI of SIMD vector types depends on target features rust-lang#116558](rust-lang#116558) The ABI of some types can change when compiling a function with different target features. This could have introduced unsoundness with target_feature_11, but recent fixes (rust-lang#133102, rust-lang#132173) either make those situations invalid or make the ABI no longer dependent on features. Thus, those issues should no longer occur. ### Special functions The `#[target_feature]` attribute is forbidden from a variety of special functions, such as main, current and future lang items (e.g. `#[start]`, `#[panic_handler]`), safe default trait implementations and safe trait methods. This was not disallowed at the time of the first stabilization PR for target_features_11, and resulted in the following issues/PRs: * [`#[target_feature]` is allowed on `main` rust-lang#108645](rust-lang#108645) * [`#[target_feature]` is allowed on default implementations rust-lang#108646](rust-lang#108646) * [#[target_feature] is allowed on #[panic_handler] with target_feature 1.1 rust-lang#109411](rust-lang#109411) * [Prevent using `#[target_feature]` on lang item functions rust-lang#115910](rust-lang#115910) ## Documentation * Reference: [Document the `target_feature_11` feature reference#1181](rust-lang/reference#1181) --- cc tracking issue rust-lang#69098 cc ```@workingjubilee``` cc ```@RalfJung``` r? ```@rust-lang/lang```
std: replace the `FromInner` implementation for addresses with private conversion functions Having these implementation available crate-wide means that platforms not using sockets for their networking code have to stub out the libc definitions required to support them. This PR moves the conversions to private helper functions that are only available where actually needed. I also fixed the signature of the function converting from a C socket address to a Rust one: taking a reference to a `sockaddr_storage` resulted in unsound usage inside `LookupHost::next`, which could create a reference to a structure smaller than `sockaddr_storage`. Thus I've replaced the argument type with a pointer and made the function `unsafe`.
Implement `read*_exact` for `std:io::repeat` cc rust-lang#136756
…=fmease Add diagnostic item for `std::io::BufRead` This will be used in Clippy to detect unbuffered calls to `Read::bytes()`.
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.
…NoDrop, r=lcnr 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`.
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.
…ust_be_overridden, r=oli-obk remove `#[rustc_intrinsic_must_be_overridde]` In rust-lang#135031, we gained support for just leaving away the body. Now that the bootstrap compiler got bumped, stop using the old style and remove support for it. r? `@oli-obk` There are a few more mentions of this attribute in RA code that I didn't touch; Cc `@rust-lang/rust-analyzer`
std: Fix another new symlink test on Windows Checking for `got_symlink_permission` first is a standard procedure for such tests.
Rollup of 8 pull requests Successful merges: - rust-lang#134655 (Stabilize `hash_extract_if`) - rust-lang#135933 (Explain how Vec::with_capacity is faithful) - rust-lang#136668 (Stabilize `core::str::from_utf8_mut` as `const`) - rust-lang#136775 (Update `String::from_raw_parts` safety requirements) - rust-lang#137109 (stabilize extract_if) - rust-lang#137349 (Implement `read_buf` for zkVM stdin) - rust-lang#137493 (configure.py: don't instruct user to run nonexistent program) - rust-lang#137516 (remove some unnecessary rustc_const_unstable) r? `@ghost` `@rustbot` modify labels: rollup
Don't doc-comment BTreeMap<K, SetValZST, A> This otherwise shows up in documentation as an empty impl block (worse, at the *top* of the docs above the public impls).
Update `compiler-builtins` to 0.1.148 Includes `f16` symbols on MIPS [1], updates for `libm` [2], and reapplies the patch that drops the `public_test_deps!` macro [3]. [1]: rust-lang/compiler-builtins#762 [2]: rust-lang/compiler-builtins#765 [3]: rust-lang/compiler-builtins#766 try-job: aarch64-gnu try-job: i686-mingw-1 try-job: i686-mingw-2 try-job: test-various try-job: x86_64-msvc-1 try-job: x86_64-msvc-2 try-job: x86_64-rust-for-linux
Signed-off-by: xizheyin <[email protected]>
Rollup of 8 pull requests Successful merges: - rust-lang#137370 (adjust_abi: make fallback logic for ABIs a bit easier to read) - rust-lang#137444 (Improve behavior of `IF_LET_RESCOPE` around temporaries and place expressions) - rust-lang#137464 (Fix invalid suggestion from type error for derive macro) - rust-lang#137539 ( Add rustdoc-gui regression test for rust-lang#137082 ) - rust-lang#137576 (Don't doc-comment BTreeMap<K, SetValZST, A>) - rust-lang#137595 (remove `simd_fpow` and `simd_fpowi`) - rust-lang#137600 (type_ir: remove redundant part of comment) - rust-lang#137602 (feature: fix typo in attribute description) r? `@ghost` `@rustbot` modify labels: rollup
Miri subtree update r? `@ghost` try-job: x86_64-gnu-aux
…isDenton Add UTF-8 validation fast paths in `Wtf8Buf` This adds two more fast paths for UTF-8 validation in `Wtf8Buf`, making use of the `is_known_utf8` flag added in rust-lang#96869 (Optimize `Wtf8Buf::into_string` for the case where it contains UTF-8). r? `@ChrisDenton`
Enable `f16` for MIPS Blocked on rust-lang/compiler-builtins#762 It seems as if `f16` works on MIPS now according to my testing on Rust master with LLVM 20, and I was asked [here](rust-lang#137167 (comment)) to create PRs with my changes. I only tested on the flavour of `mipsel-unknown-linux-gnu` hardware that happens to be available to me, so I can't say anything about other MIPS hardware, but from a casual skimming of the LLVM code ([1], [2]) it seems like `f16` should work on all MIPS hardware. So enable it for all MIPS hardware. [1]: https://github.com/rust-lang/llvm-project/blob/rustc/20.1-2025-02-13/llvm/lib/Target/Mips/MipsISelLowering.h#L370 [2]: https://github.com/rust-lang/llvm-project/blob/rustc/20.1-2025-02-13/llvm/lib/CodeGen/TargetLoweringBase.cpp#L1367-L1388 `@rustbot` label +O-MIPS +F-f16_and_f128 +S-blocked Tracking issue for f16: rust-lang#116909 r? `@tgross35`
fix doc in library/core/src/pin.rs Fixes rust-lang#134874
remove `MaybeUninit::uninit_array` Closes rust-lang#134584. Closes rust-lang#66845. The future of this unstable method was described in rust-lang#125082 (comment). Since `inline_const` was stabilized in 1.79 (4 stable releases away) and no one expressed interest for keeping it in rust-lang#96097, I think it can be removed now as it is not a stable method.
Use less CString in the examples of CStr. Fixes rust-lang#83999
…, r=ChrisDenton Fix `attr` cast for espidf rust-lang#136826 broke ESP-IDF builds with: https://github.com/esp-rs/esp-idf-template/actions/runs/13516221587/job/37765336588. This PR fixes it. cc: ``@ivmarkov`` ``@xizheyin``
…ct, r=ibraheemdev add `IntoBounds::intersect` and `RangeBounds::is_empty` - ACP: rust-lang/libs-team#539 - Tracking issue for `is_empty`: rust-lang#137300 - Tracking issue for `IntoBounds`: rust-lang#136903
…ubilee Return unexpected termination error instead of panicing in `Thread::join` There is a time window during which the OS can terminate a thread before stdlib can retreive its `Packet`. Currently the `Thread::join` panics with no message in such an event, which makes debugging difficult; fixes rust-lang#124466.
Update some comparison codegen tests now that they pass in LLVM20 Fixes rust-lang#106107 Needed one tweak to the default `PartialOrd::le` to get the test to pass. Everything but the derived 2-field `le` test passes even without the change to the defaults in the trait.
… r=RalfJung import `simd_` intrinsics In most cases, we can import the simd intrinsics rather than redeclare them. Apparently, most of these tests were written before `std::intrinsics::simd` existed. There are a couple of exceptions where we can't yet import: - the intrinsics are not declared as `const fn` in the standard library, causing issues in the `const-eval` tests - the `simd_shuffle_generic` function is not exposed from `std::intrinsics` - the `simd_fpow` and `simd_fpowi` functions are not exposed from `std::intrinsics` (removed in rust-lang#137595) - some tests use `no_core`, and therefore cannot use `std::intrinsics` r? ```@RalfJung``` cc ```@workingjubilee``` do you have context on why some intrinsics are not exposed?
…lnay
Fix Windows `Command` search path bug
Currently `Command::new` on Windows works differently depending on whether any environment variable is set. For example,
```rust
// Searches for "myapp" in the application and system paths first (aka Windows native behaviour).
Command::new("myapp").spawn();
// Search for "myapp" in `PATH` first
Command::new("myapp").env("a", "b").spawn();
```
This is a bug because the search path should only change if `PATH` is changed for the child (i.e. `.env("PATH", "...")`).
This was discussed in a libs-api meeting where the exact semantics of `Command::new` was not decided but there seemed to be broad agreement that this particular thing is just a bug that can be fixed.
r? libs-api
…oss35 checked_ilog tests: deal with a bit of float imprecision Fixes rust-lang#137591 r? `@tgross35`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an automated PR to update the subtree/library branch to the changes
from 2025-02-11 (6171d94)
to 2025-03-02 (8c39296), inclusive.
Do not merge this PR using the merge queue. Instead, use the rebase strategy.