Rollup of 15 pull requests - #163071
Open
JonathanBrouwer wants to merge 31 commits into
Open
Rollup of 15 pull requests#163071JonathanBrouwer 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 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.
…Urgau [rustdoc] Correctly handle `dyn` trait methods linking for jump to def feature Part of the missing pieces for rust-lang#162808 to work. The issue was that in case we had the method of a dyn trait, we tried to use the dyn trait as is and couldn't generate a correct href to its `DefId`. If we get the trait in the `dyn`, it works just as expected. r? @Urgau
…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
|
@bors r+ p=5 |
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
…uwer Rollup of 15 pull requests Successful merges: - #162726 (std: fix unix socket address panic on a full sun_path) - #163016 (Don't claim that escaping value is a reference in diagnostics) - #163040 (Tweak "use array's length as const param" suggestion) - #163060 (Point to fields that introduce trait requirements) - #163066 (don't mark `f128` as reliable on AIX) - #162098 (Tweak `Infallible` docs) - #162854 (Add safety section for atomic_load/store) - #163015 (add `minicore::ffi::VaList`) - #163021 (`va_arg`: pass in `TyAndLayout`) - #163036 ([rustdoc] Correctly handle `dyn` trait methods linking for jump to def feature) - #163042 (Remove redundant output from suggestion) - #163046 (Use verbose suggestion for `const _`) - #163050 (Use verbose suggestion for similarly named label suggestion) - #163052 (Use verbose suggestion for wrong primitive type names) - #163055 (Use the full path of `bug_impl` to avoid bogus errors in rust-analyzer)
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
rust-bors
Bot
added
S-waiting-on-review
Contributor
|
💔 Test for fa9ef92 failed: CI. Failed job:
|
Member
Author
rust-bors
Bot
added
S-waiting-on-bors
Contributor
|
⌛ Trying commit 467486f with merge 42ca280… To cancel the try build, run the command Workflow: https://github.com/rust-lang/rust/actions/runs/35526009750 |
rust-bors Bot
pushed a commit
that referenced
this pull request
Sep 20, 2026
Rollup of 15 pull requests try-job: test-x86_64-gnu-llvm-21-2
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
11 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)dyntrait methods linking for jump to def feature #163036 ([rustdoc] Correctly handledyntrait methods linking for jump to def feature)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