Rollup of 14 pull requests#160003
Open
JonathanBrouwer wants to merge 42 commits into
Open
Conversation
Use the one that's passed in.
- By improving various comments. - By renaming some fields. This gives a clear split between `move_outs`/`move_out_loc_map`/`move_out_path_map` and `inits`/`init_loc_map`/`init_path_map`.
By using an iterator instead of a manual loop.
It always has the same value as `mark_inactive_variants_as_uninit`, and it's only read if `mark_inactive_variants_as_uninit` is true.
Several changes: ## Link `symlink_metadata` from `metadata` Someone reading `metadata` likely wants easy/quick access to `symlink_metadata` as well. Since this explicitly documents that it does follow symlinks, it made sense to leave a note stating how to perform the same action without that behavior. ## Add symbolic link note to errors It's intuitive that you cannot return the `Metadata` of a resolved file if the file could not be resolved. But it's not always obvious. Since we're stating "the path does not exist" (also an obvious case). It will help to have this gentle reminder. ## Explicit behavior of directories and files in `symlink_metadata` Reading the documentation, it was unclear whether `symlink_metadata` would also work on files and directories. I guessed it would, but it's nice to call it out. The wording also gave me an opportunity to cross-link to `metadata` so someone can easily jump back and forth between them.
Co-authored-by: Dominik Schwaiger <mail@dominik-schwaiger.ch>
The MIPS n64 ABI returns structs that meet the following requirements: - Up to 128 bits large - Only one or two fields, all of which are floating point - Offset of the first field is zero in floating point registers. This was already accounted for, but the edge case of a struct with a single f128 field was not handled correctly and would always be returned in integer registers. If we tell the backend to use a f128 register here, LLVM will return the value in two of the 64-bit FPRs, $f0 and $f2. That is equivalent to how Clang, GCC and also Rustc today would return a long double / f128. However, both Clang and GCC return a struct with a single long double field in $f0 and $f1. In order to achieve the same result in Rustc, we need to set the InReg attribute on the return value. With this, we now match Clang and GCC. Clang: https://godbolt.org/z/za8qv9P4n GCC: https://godbolt.org/z/9qcdGsce6 Rustc currently: https://godbolt.org/z/8sP5G4ash LLVM IR comparisons: https://godbolt.org/z/ojaTTY9hW
``` error: expected one of `.`, `?`, `]`, or an operator, found `,` --> $DIR/do-not-suggest-semicolon-between-macro-without-exclamation-mark-and-array.rs:2:19 | LL | let _x = vec[1, 2, 3]; | ^ expected one of `.`, `?`, `]`, or an operator | help: you might have meant to call a macro | LL | let _x = vec![1, 2, 3]; | + ```
VxWorks has no process groups: the SDK defines no `killpg`, and `getpgrp`/`setpgid` are no-ops in libunix, so `kill(-pgrp, sig)` is no substitute either. libc cannot usefully declare `killpg` for this target, so calling it leaves the target unable to build std. Panic instead, matching what fuchsia does for the same method.
…e-ice, r=petrochenkov Avoid ICE when cfg_eval recovers no item from derive input Fixes rust-lang#148891 `cfg_eval` reparses derive input when it contains `#[cfg]` or `#[cfg_attr]` so it can capture cfg positions in the token stream. That reparse can emit syntax errors and return `Ok(None)` when parser recovery cannot reconstruct an item. This pr changes the reparse path to return `Option<Annotatable>` and fall back to the original annotatable when recovery produces no node.
…, r=folkertdev Fix decoding attributes of `SyntheticCoroutineBody` Fixes rust-lang#156905 by returning an empty list of attributes for `SyntheticCoroutineBody` when its attributes are decoded
…Mark-Simulacrum feat: Update method signature of int_from_ascii * Tracking issue: rust-lang#134821 Following [discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/327149-t-libs-api.2Fapi-changes/topic/How.20to.20proceed.20with.20int_from_ascii/with/611508226) it appears the preference is to change the API for this feature as follows: ```rust // core::num impl X { pub const fn from_ascii_bytes<T>(src: T) -> Result<X, ParseIntError> where T: [const] AsRef<[u8]> + [const] core::marker::Destruct; pub const fn from_ascii_bytes_radix<T>(src: T, radix: u32) -> Result<X, ParseIntError> where T: [const] AsRef<[u8]> + [const] core::marker::Destruct; } ``` and similarly for `NonZero<X>`. Reasons behind the change: * Future-proof the naming convention for future string-like types * Support the upcoming `ByteStr`/`ByteString` types: rust-lang#134915 This pull request applies this change. The const-ness of these functions is now feature gated behind rust-lang#143773
… r=cjgillot Some place analysis tweaks Details in individual commits. r? @cjgillot
…=ShoyuVanilla Normalize region obligations before regionck We now normalize `TypeOutlives` predicates when evaluating them in the next solver. So we don't need to normalize in regionck anymore. r? @ShoyuVanilla cc @lcnr
…s, r=clarfonthey sanitize_standard_fds: Miri supports poll now However, so far it doesn't support it on the standard FDs (0..=2). So let's support those in poll and then remove a Miri special case in std.
…gle-f128, r=folkertdev rustc_target: callconv: mips64: Return structs with single f128 in FPRs The MIPS n64 ABI returns structs that meet the following requirements: - Up to 128 bits large - Only one or two fields, all of which are floating point - Offset of the first field is zero in floating point registers. This was already accounted for, but the edge case of a struct with a single `f128` field was not handled correctly and would always be returned in integer registers. If we tell the backend to use a `f128` register here, LLVM will return the value in two of the 64-bit FPRs, `$f0` and `$f2`. That is equivalent to how Clang, GCC and also Rustc today would return a `long double` / `f128`. However, both Clang and GCC return a struct with a single long double field in `$f0` and `$f1`. In order to achieve the same result in Rustc, we need to set the `InReg` attribute on the return value. With this, we now match Clang and GCC. Clang: https://godbolt.org/z/za8qv9P4n GCC: https://godbolt.org/z/9qcdGsce6 Rustc currently: https://godbolt.org/z/8sP5G4ash LLVM IR comparisons: https://godbolt.org/z/ojaTTY9hW --- I'm not sure if it is acceptable to use `Reg::f128` since MIPS has no 128-bit floating point registers unless MSA is present. LLVM lowers it correctly to use two FPRs, not sure if this would cause issues with GCC. `f16` probably also needs some changes here, but I'll do that as a follow-up. --- r? @folkertdev and Folkert also told me to cc @tgross35 :)
…athanBrouwer Add suggestions for using `#[export_name]` instead of `#[link_name]` on static Fixes rust-lang#159247. This adds a suggestion for using `#[unsafe(export_name = "...")]` when `#[link_name = "..."]` is applied to a static. It also handles the existing `#[unsafe(link_name = "...")]` form by replacing only the attribute name. Tested with: - `./x test tests/ui/attributes/link-name-on-static.rs` - `./x test tests/ui/attributes/unsafe-link-name-on-static.rs`
…_docs, r=joshtriplett Expand docs for fs::metadata and fs::symlink_metadata Several changes: ## Link `symlink_metadata` from `metadata` Someone reading `metadata` likely wants easy/quick access to `symlink_metadata` as well. Since this explicitly documents that it does follow symlinks, it made sense to leave a note stating how to perform the same action without that behavior. ## Add symbolic link note to errors It's intuitive that you cannot return the `Metadata` of a resolved file if the file could not be resolved. But it's not always obvious. Since we're stating "the path does not exist" (also an obvious case). It will help to have this gentle reminder. ## Explicit behavior of directories and files in `symlink_metadata` Reading the documentation, it was unclear whether `symlink_metadata` would also work on files and directories. I guessed it would, but it's nice to call it out. The wording also gave me an opportunity to cross-link to `metadata` so someone can easily jump back and forth between them.
Update expect message using the recommended style in binary_heap module Related issue: rust-lang#159751
…-mode, r=adwinwhite Fix opaque type ICE in late lints under the next-generation trait solver fixes rust-lang/rust-clippy#17411 Under the next trait solver, late lints trigger an ICE due to having non-empty opaque storage when dropping `InferCtxt`. Rather than forcing all current and future late lints to manually use `ignoring_regions`, use `PostBorrowck` in `LateContext`. cc @adwinwhite
…23, r=Mark-Simulacrum Fix observable intermediate state in `thread::add_spawn_hook` Fixes rust-lang#159923. Ensures the intermediate state of there being no hooks in `add_spawn_hooks` is not observable by allocating the new head node before taking the current hook list. Also added a note to the docs of `add_spawn_hook` that hooks are not guaranteed to run and cannot be relied upon for soundness, as there are multiple ways to prevent all/some hooks from running.
…upported, r=Darksonn std: make send_process_group_signal unsupported on VxWorks `x86_64-wrs-vxworks` doesn't build std: `cargo new` plus `-Zbuild-std` stops with E0425 on `libc::killpg`, which rust-lang#156539 introduced. libc has never declared `killpg` for vxworks, and declaring it wouldn't help. On wrsdk-vxworks7-qemu-1.17.0 there's no `killpg` in the headers, the sysroot archives or the prebuilt kernel, and `getpgrp`/`setpgid` are no-ops in libunix: `getpgrp` returns a constant 0, `setpgid` stores nothing. That rules out `kill(-pgrp, sig)` too. `Command::process_group` is already ignored on this target, since `get_pgroup` is only read by the fork/posix_spawn path while vxworks spawns through `rtpSpawn`. Closes rust-lang#159969.
Detect when a macro without exclamation mark uses square brackets ``` error: expected one of `.`, `?`, `]`, or an operator, found `,` --> $DIR/do-not-suggest-semicolon-between-macro-without-exclamation-mark-and-array.rs:2:19 | LL | let _x = vec[1, 2, 3]; | ^ expected one of `.`, `?`, `]`, or an operator | help: you might have meant to call a macro | LL | let _x = vec![1, 2, 3]; | + ``` Fix rust-lang#101490.
rustbot
added
A-attributes
Contributor
Author
Contributor
rust-bors
Bot
added
S-waiting-on-bors
Contributor
|
⌛ Trying commit 661e2d1 with merge 7112b60… To cancel the try build, run the command Workflow: https://github.com/rust-lang/rust/actions/runs/30256180418 |
rust-bors Bot
pushed a commit
that referenced
this pull request
Jul 27, 2026
Rollup of 14 pull requests try-job: dist-various-1 try-job: test-various try-job: x86_64-gnu-aux try-job: x86_64-gnu-llvm-21-3 try-job: x86_64-msvc-1 try-job: aarch64-apple try-job: x86_64-mingw-1 try-job: i686-msvc-*
Contributor
Author
|
@bors p=1000 |
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
15 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:
SyntheticCoroutineBody#159085 (Fix decoding attributes ofSyntheticCoroutineBody)#[export_name]instead of#[link_name]on static #159253 (Add suggestions for using#[export_name]instead of#[link_name]on static)thread::add_spawn_hook#159956 (Fix observable intermediate state inthread::add_spawn_hook)r? @ghost
Create a similar rollup