Rollup of 15 pull requests - #163069
Closed
JonathanBrouwer wants to merge 31 commits into
Closed
Rollup of 15 pull requests#163069JonathanBrouwer wants to merge 31 commits into
JonathanBrouwer wants to merge 31 commits into
Conversation
linux reports an address length one byte past sockaddr_un when the path fills sun_path without a NUL, which made address() slice out of bounds since e96993c. cap the length at the size of sockaddr_un.
The inline suggestion message already includes the code to replace.
- Don't suggest braces unnecessarily for numeric literals - Use verbose suggestion - Tweak messages ``` error[E0747]: type provided when a constant was expected --> $DIR/suggest_const_for_array.rs:6:15 | LL | example::<[usize; 3]>(); | ^^^^^^^^^^ array type provided where a `usize` was expected | help: you might have meant to use the array's length's value | LL - example::<[usize; 3]>(); LL + example::<3>(); | ```
Link to the never type and restore the note about possibly deprecating in the future.
```
warning: non-local `impl` definition, `impl` blocks should be written at the same level as their item
--> $DIR/consts.rs:13:5
|
LL | const Z: () = {
| ----------- move the `impl` block outside of this constant `Z`
...
LL | impl Uto for &Test {}
| ^^^^^---^^^^^^----
| | |
| | `Test` is not local
| `Uto` is not local
|
= note: an `impl` is never scoped, even when it is nested inside an item, as it may impact type checking outside of that item, which can be the case if neither the trait or the self type are at the same nesting level as the `impl`
= note: items in an anonymous const item (`const _: () = { ... }`) are treated as in the same scope as the anonymous const's declaration for the purpose of this lint
= note: `#[warn(non_local_definitions)]` on by default
help: use a const-anon item to suppress this lint
|
LL - const Z: () = {
LL + const _: () = {
|
```
``` error[E0425]: cannot find type `double` in this scope --> $DIR/recommend-literal.rs:1:13 | LL | type Real = double; | ^^^^^^ not found in this scope | help: you might have intended to use the `f64` primitive type | LL - type Real = double; LL + type Real = f64; | ```
For whatever reason, rust-analyzer doesn't understand hygienic macros well enough to properly resolve this function call, which leads to bogus type errors appearing in rust-analyzer because it doesn't know that the function returns `!` and therefore must diverge. (For example, if `bug!(..);` with a trailing semicolon is used in the else block of a let-else statement, rust-analyzer will complain about it even though rustc is happy.) If we specify the full path to the function, both rustc and rust-analyzer agree that it diverges.
weird I did not spot this before, it cleans up the code a bunch
In fact the type is really not supported at all there.
…imulacrum std: fix unix socket address panic on a full sun_path linux reports an address length one byte past sockaddr_un when the path fills sun_path without a NUL, which made address() slice out of bounds since e96993c. cap the length at the size of sockaddr_un.
…ce-then-nothing-is, r=estebank Don't claim that escaping value is a reference in diagnostics Changes the part of the "borrowed data escapes" diagnostic that points to the local that the region came from, by removing the claim that it is a reference, as that is not generally correct. Fixes rust-lang#162890 I considered checking if the type of the escaping value is actually a reference type (and keeping the old message if so). But with the way the code is written, that would have been non-trivial to do, and of questionable value (the type is already shown in the error). Also, IMO the new message is more "to the point", even for references. r? compiler
…anted, r=fmease Tweak "use array's length as const param" suggestion - Don't suggest braces unnecessarily for numeric literals - Use verbose suggestion - Tweak messages ``` error[E0747]: type provided when a constant was expected --> $DIR/suggest_const_for_array.rs:6:15 | LL | example::<[usize; 3]>(); | ^^^^^^^^^^ array type provided where a `usize` was expected | help: you might have meant to use the array's length's value | LL - example::<[usize; 3]>(); LL + example::<3>(); | ```
…end-field-location, r=nnethercote Point to fields that introduce trait requirements Fixes rust-lang#146016
don't mark `f128` as reliable on AIX In fact the type is really not supported at all there. In rust-lang#162979 we made `f128` reliable on powerpc64 when the `vsx` feature is enabled. Apparently this is the case on AIX, but it just does not implement `f128` at all. r? tgross35
…fonthey Tweak `Infallible` docs Adds a hyperlink to the never type. I restored a statement that `Infallible` may be deprecated in a future version. That was (unintentionally?) lost in the stabilization PR. cc @WaffleLapkin
Add regression tests for issues marked fixed-by-next-solver (2/N) Note that while these issues are marked `fixed-by-next-solver`, they also pass with the old solver now. Closes rust-lang#129372 Closes rust-lang#155151 Closes rust-lang#155092 Closes rust-lang#146813 Closes rust-lang#142832
Add safety section for atomic_load/store This PR tries to add `# Safety` section for atomic_load/store in intrinsic module. I notice that some intrinsic unsafe functions already have `# Safety` section. And for these two functions, they have corresponding stable version functions in `core/sync`. But in the stable implementation, I notice that they first call an unsafe `atomic_load/store` defined in the same file(a private function without safety doc), and that unsafe function directly call `atomic_load/store` defined in intrinsic module(for example, [atomic_load](https://doc.rust-lang.org/std/intrinsics/fn.atomic_load.html)). Here is the implementaion of [atomic_load](https://doc.rust-lang.org/src/core/sync/atomic.rs.html#3886) used in AtomicBool::load: ```rust #[inline] #[cfg_attr(miri, track_caller)] // even without panics, this helps for Miri backtraces unsafe fn atomic_load<T: Copy>(dst: *const T, order: Ordering) -> T { // SAFETY: the caller must uphold the safety contract for `atomic_load`. unsafe { match order { Relaxed => intrinsics::atomic_load::<T, { AO::Relaxed }>(dst), Acquire => intrinsics::atomic_load::<T, { AO::Acquire }>(dst), SeqCst => intrinsics::atomic_load::<T, { AO::SeqCst }>(dst), Release => panic!("there is no such thing as a release load"), AcqRel => panic!("there is no such thing as an acquire-release load"), } } } ``` So I'm trying to add `# Safety` section for the intrinsic atomic_load/store. Although intrinsic API mainly used for Rust standary library, I think that adding `# Safety` section is needed because it pass a raw pointer. When writing the `# Safety` section for these two functions, I refer to [read_volatile](https://doc.rust-lang.org/std/ptr/fn.read_volatile.html) and [write_volatile](https://doc.rust-lang.org/std/ptr/fn.write_volatile.html). If needed, I will review all the atomic operations defined in intrinsic module. Thank you for your review and I'm looking forward to your feedback. Hoping this PR can improve the safety doc of Rust standard library.
…youxu add `minicore::ffi::VaList` Now that `VaList` is stable (on beta, but, this definition should not change, it implements a specification), we can add the definition to `minicore`. We're not adding `VaArgSafe` because it is still in flux, and not really needed for the tests: we just need to only test types that are relevant for a particular target. r? jieyouxu or @beetrees
…=adwinwhite `va_arg`: pass in `TyAndLayout` Just a refactor, no functional changes. It is weird I did not spot this before, it cleans up the code a bunch.
…ut-borrow, r=jieyouxu Remove redundant output from suggestion The inline suggestion message already includes the code to replace.
Use verbose suggestion for `const _`
```
warning: non-local `impl` definition, `impl` blocks should be written at the same level as their item
--> $DIR/consts.rs:13:5
|
LL | const Z: () = {
| ----------- move the `impl` block outside of this constant `Z`
...
LL | impl Uto for &Test {}
| ^^^^^---^^^^^^----
| | |
| | `Test` is not local
| `Uto` is not local
|
= note: an `impl` is never scoped, even when it is nested inside an item, as it may impact type checking outside of that item, which can be the case if neither the trait or the self type are at the same nesting level as the `impl`
= note: items in an anonymous const item (`const _: () = { ... }`) are treated as in the same scope as the anonymous const's declaration for the purpose of this lint
= note: `#[warn(non_local_definitions)]` on by default
help: use a const-anon item to suppress this lint
|
LL - const Z: () = {
LL + const _: () = {
|
```
…rtdev
Use verbose suggestion for similarly named label suggestion
```
error[E0425]: cannot find value `while_loop` in this scope
--> $DIR/label_misspelled.rs:32:15
|
LL | 'while_loop: while true {
| ----------- a label with a similar name exists
LL | break while_loop;
| ^^^^^^^^^^ not found in this scope
|
help: use the similarly named label
|
LL | break 'while_loop;
| +
```
Use verbose suggestion for wrong primitive type names ``` error[E0425]: cannot find type `double` in this scope --> $DIR/recommend-literal.rs:1:13 | LL | type Real = double; | ^^^^^^ not found in this scope | help: you might have intended to use the `f64` primitive type | LL - type Real = double; LL + type Real = f64; | ```
Use the full path of `bug_impl` to avoid bogus errors in rust-analyzer For whatever reason, rust-analyzer doesn't understand hygienic macros well enough to properly resolve this function call, which leads to bogus type errors appearing in rust-analyzer because it doesn't know that the function returns `!` and therefore must diverge. (For example, if `bug!(..);` with a trailing semicolon is used in the else block of a let-else statement, rust-analyzer will complain about it even though rustc is happy.) If we specify the full path to the function, both rustc and rust-analyzer agree that it diverges. --- I noticed this problem when rust-analyzer started flagging a lot more bogus warnings after rust-lang#161873. Thankfully the workaround is very simple, so we don't really lose much by catering to rust-analyzer here. There should be no change to compiler behaviour.
rustbot
added
A-LLVM
Member
Author
Contributor
rust-bors
Bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
pushed a commit
that referenced
this pull request
Sep 20, 2026
Rollup of 15 pull requests try-job: dist-various-1 try-job: test-various try-job: test-x86_64-gnu-aux try-job: test-x86_64-gnu-llvm-21-3 try-job: test-x86_64-msvc-1 try-job: test-aarch64-apple-1 try-job: test-aarch64-apple-2 try-job: test-x86_64-mingw-1 try-job: test-i686-msvc try-job: test-armhf-gnu
rust-bors
Bot
added
S-waiting-on-author
Contributor
|
PR #162145, which is a member of this rollup, was unapproved. This rollup was thus unapproved. |
rustbot
removed
the
S-waiting-on-author
Contributor
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
10 participants
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.
Successful merges:
f128as reliable on AIX #163066 (don't markf128as reliable on AIX)Infallibledocs #162098 (TweakInfallibledocs)minicore::ffi::VaList#163015 (addminicore::ffi::VaList)va_arg: pass inTyAndLayout#163021 (va_arg: pass inTyAndLayout)const _#163046 (Use verbose suggestion forconst _)bug_implto avoid bogus errors in rust-analyzer #163055 (Use the full path ofbug_implto avoid bogus errors in rust-analyzer)r? @ghost
Create a similar rollup