Rollup of 16 pull requests - #162186
Closed
JonathanBrouwer wants to merge 55 commits into
Closed
Conversation
Signed-off-by: arferreira <arfs.antonio@gmail.com>
Previously, these tests were testing the wrong feature gate, and had unnecessary type errors.
This is done so that we can test whether the location used is at the function call site or the await site.
Co-authored-by: Ralf Jung <post@ralfj.de>
- Rename `generate_*` functions to `emit_*`, since they emit LLVM globals - Consistently use qualified paths in `counter_for_term` - Remove an unnecessary Clone from `llvm_cov::Regions`
One of the key tasks in coverage codegen is to take the source-code spans that were recorded during MIR instrumentation, and resolve them to physical coordinates in their respective files. In rare cases this resolution can fail, which leads to the awkward possibility that a function might lose _all_ of its mappings for a particular file/expansion. If that happens, we need to avoid emitting a covfun file section containing no regions, because doing so would trigger errors in LLVM. The existing code does handle this edge case, but in a way that won't generalise to multiple files/expansions. Having an explicit intermediate resolution step will make it easier to add support for expansion regions in the future.
`suggest_fn_call` only fired when the failing obligation came from `ObligationCauseCode::FunctionArg`, so a fn item or closure used as the iterator of a `for` loop got no structured suggestion to call it. the iterator of a `for` loop is passed to `IntoIterator::into_iter`, so the failing `Iterator` goal is a derived obligation and the cause span carries the loop desugaring, which makes `can_be_used_for_suggestions` return false. carry the `HirId` of the iterator expression in `ObligationCauseCode::ForLoopIterator` and gate the suggestion on the span of that expression instead. rust-lang#161564
dereferencing an uncalled function only said the function type cannot be dereferenced. it now suggests the call, gated on the return type actually being dereferenceable. rust-lang#161564 (comment)
…low` VxWorks' libc defines no `O_NOFOLLOW`, so building std for x86_64-wrs-vxworks stopped compiling once `set_perm_nofollow` was consolidated into `sys/fs/unix.rs` without a vxworks guard. VxWorks also has no way to express a no-follow permission change: its `fchmodat` rejects `AT_SYMLINK_NOFOLLOW` with `ENOTSUP`. Return `Unsupported`, matching the existing Android stub.
And only include the target name when rendering test metadata, to avoid including filenames in it.
… of targets to check
Make it also enabled by default just like it is for clang.
Our `LLVMRustVersion*` functions get hard-coded `LLVM_VERSION_*` values when we build `RustWrapper.cpp`, but this could be different than the actual LLVM library at runtime. This should never happen with toolchains from `rustup`, but with external LLVM in a distro build, for example, `rustc` and `LLVM` can be upgraded independently. Most of the time when we check the LLVM version, we're only looking at the major version anyway, and we already assert that these are equal in `configure_llvm`. However, for anything that does check the minor or patch version too, the runtime version is probably more relevant.
This reverts commit 5a5b84a.
`LoweringContext` has 14 fields that get swapped in and out in `with_hir_id_owner`. This is fragile and gross. This commit moves those fields into a new struct, `PerOwnerLoweringState`, which means they can be swapped in and out cleanly. Other changes: - All `self.foo` accesses to those 14 fields become `self.curr_owner.foo`. - Field renames: - `current_hir_id_owner` -> `owner_id` - `current_disambiguator` -> `disambiguator` - `LoweringContext::make_owner_info` becomes `PerOwnerLoweringState::into_owner_info`; this makes sense because it consumes the `PerOwnerLoweringState`. - Stronger assertions: `into_owner_info` has assertions that now apply to the `with_lctx` path as well as the `with_hir_id_owner` path.
…ths, r=estebank Normalize .. and . in diagnostic file paths Fixes rust-lang#51349 Lexically normalize `.` and `..` in file paths when rendering diagnostics, so errors show `foo.rs` instead of `sub/../foo.rs`. Normalization is scoped to the new `FileNameDisplayPreference::Diagnostics` variant used by `SourceMap::filename_for_diagnostics`; `file!()`, debuginfo, and remapped/local/short paths are unchanged. Uses the unstable `Path::normalize_lexically`, `canonicalize` is avoided because it turns relative paths absolute, which broke the previous attempt in rust-lang#83345. Paths that `normalize_lexically` rejects (leading escapes, net-negative `..`) fall back to the raw path and don't occur in practice for the diagnostic paths this PR targets. Compiletest gains a `$DIR/..` substitution so existing `.stderr` files that referenced auxiliary paths above `$DIR` keep matching. Previous attempt was rust-lang#68654. r? @estebank
…r=jieyouxu Run mir-opt panic=abort tests on CI Context: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Blessing.20mir-opt.20on.20a.20clean.20checkout.20produces.20a.20diff/near/613465816 It looks like we didn't run them on CI (ever? lol). r? @RalfJung
volatile: allow accesses to non-AM memory to trap Fixes rust-lang/unsafe-code-guidelines#610 by saying that yes, volatile accesses may trap. This also fixes what I believe to be the last case of "time-traveling UB" we have in Rust: with this change, UB always fully sequenced wrt observable events (I/O and volatile accesses). UB can still travel around unobservable events such as non-volatile memory accesses. For writes, LLVM has already implemented the new semantics for a long time. For reads, LLVM only recently implemented the "may trap" semantics with LLVM 23. We still allow compiling rustc with older versions of LLVM. To (hopefully) prevent old LLVM from screwing this up with optimizations, this PR makes the backend emit an inline asm block *without* `willreturn`, which should prevent optimizations that break programs where a volatile load traps. Cc @rust-lang/opsem @rust-lang/wg-llvm
…m-in-for-loop, r=estebank suggest calling a fn item used as the iterator of a `for` loop `suggest_fn_call` only fired when the failing obligation came from `ObligationCauseCode::FunctionArg`, so a fn item or closure used as the iterator of a `for` loop got no structured suggestion to call it. the iterator of a `for` loop is passed to `IntoIterator::into_iter`, so the failing `Iterator` goal is a derived obligation and the cause span carries the loop desugaring, which makes `can_be_used_for_suggestions` return false. carry the `HirId` of the iterator expression in `ObligationCauseCode::ForLoopIterator` and gate the suggestion on the span of that expression instead. fixes rust-lang#161564 r? @oli-obk
coverage: Resolve spans to file-coordinates in a separate step One of the key tasks in coverage codegen is to take the source-code spans that were recorded during MIR instrumentation, and resolve them to physical coordinates in their respective files. In rare cases this resolution can fail, which leads to the awkward possibility that a function might lose _all_ of its mappings for a particular file/expansion. If that happens, we need to avoid emitting a covfun file section containing no regions, because doing so would trigger errors in LLVM. The existing code does handle this edge case, but in a way that won't generalise to multiple files/expansions. Having an explicit intermediate resolution step will make it easier to add support for expansion regions in the future. There should be no change to compiler output.
… r=spastorino Introduce `PerOwnerLoweringState` `LoweringContext` has 14 fields that get swapped in and out in `with_hir_id_owner`. This is fragile and gross. This commit moves those fields into a new struct, `PerOwnerLoweringState`, which means they can be swapped in and out cleanly. Other changes: - All `self.foo` accesses to those 14 fields become `self.curr_owner.foo`. - Field renames: - `current_hir_id_owner` -> `owner_id` - `current_disambiguator` -> `disambiguator` - `LoweringContext::make_owner_info` becomes `PerOwnerLoweringState::into_owner_info`; this makes sense because it consumes the `PerOwnerLoweringState`. - Stronger assertions: `into_owner_info` has assertions that now apply to the `with_lctx` path as well as the `with_hir_id_owner` path. r? @spastorino
Test itanium mangling of `f16` and `f128` And fix the string that is used for `f128` on powerpc targets, where the standard `"g"` is already taken by `__ibm128`. In clang https://github.com/llvm/llvm-project/blob/bd5b1f58ae58cceab2cadb882cceb1d96f4ad33e/clang/lib/Basic/Targets/PPC.h#L362-L363 ```c const char *getFloat128Mangling() const override { return "u9__ieee128"; } const char *getIbm128Mangling() const override { return "g"; } ``` and GCC https://github.com/gcc-mirror/gcc/blob/fc54ab94ad257f9ef43a7287a60c21734a7a288f/gcc/config/rs6000/rs6000.cc#L20795-L20801 ```c if (SCALAR_FLOAT_TYPE_P (type) && FLOAT128_IBM_P (TYPE_MODE (type))) return "g"; if (SCALAR_FLOAT_TYPE_P (type) && FLOAT128_IEEE_P (TYPE_MODE (type))) return "u9__ieee128"; ``` From what i can tell this is not really testable for powerpc at the moment because CFI is not supported on powerpc. r? tgross35
…,WaffleLapkin Don't special-case `!` in stability checks anymore Two instances of special-casing: - one for `!`, added in rust-lang#76538 (nearly 6 years ago, Rust v1.48), back when `!` was unstable, - one for `fn() -> !` in rust-lang#103239 (nearly 4 years ago, Rust v1.66), because `-> !` was allowed on stable even with `!` being unstable. Since then, in rust-lang#103239 (just a week ago, on track to be part of Rust v1.100), `!` was stabilized, so the first check became wrong and the second became redundant. Let's remove them. Fixes rust-lang#162116.
…nwhite fuchsia: Add safestack as a supported sanitizer for x86_64 fuchsia Make it also enabled by default just like it is for clang.
…s, r=ShoyuVanilla Improve tests for `#[track_caller]` in async Tracking issue for `async_fn_track_caller`: rust-lang#110011 Tracking issue for `closure_track_caller`: rust-lang#87417 I recommend reviewing each commit individually. cc @RalfJung, who requested the test to be added to Miri. --- For your convenience, below is the output of `diff tests/ui/async-await/track-caller/panic-track-caller.rs src/tools/miri/tests/pass/async-panic-track-caller.rs`: ```diff 2c2 < // src/tools/miri/tests/pass/async-panic-track-caller.rs --- > // tests/ui/async-await/track-caller/panic-track-caller.rs 4,6d3 < // FIXME: catch_unwind is broken in gcc. Will be fixed in the next rustc_codegen_gcc sync. < //@ ignore-backends: gcc < //@ run-pass 9,10c6,10 < //@ needs-unwind < // gate-test-async_fn_track_caller --- > // > // > // > // > // Padding comment so that the line numbers are the same as panic-track-caller.rs 58a59 > #[cfg_attr(any(cls, nofeat), expect(ungated_async_fn_track_caller))] 60d60 < //[cls,nofeat]~^ WARN `#[track_caller]` on async functions is a no-op 72a73 > #[cfg_attr(any(cls, nofeat), expect(ungated_async_fn_track_caller))] 74d74 < //[cls,nofeat]~^ WARN `#[track_caller]` on async functions is a no-op 107a108 > #[cfg_attr(any(cls, nofeat), expect(ungated_async_fn_track_caller))] 109d109 < //[cls,nofeat]~^ WARN `#[track_caller]` on async functions is a no-op ```
…fee1-dead Render the `box` pattern removal diagnostic more actionable & remove `box` expression recovery Follow-up to rust-lang#156749. This way, users don't have to comb through (probably outdated) tracking issues trying to piece together how to fix their code (in the most idiomatic way). Lemme know if you think this is unnecessary. Re. `box` expression removal, see rust-lang#162008 (comment) (TL;DR: it's been 3 years). cc @cyrgani <sub>(No LLM was or will be used by me during the entire creation process of this PR)</sub>
…, r=ChrisDenton std: don't reference `libc::O_NOFOLLOW` on VxWorks in `set_perm_nofollow` `set_permissions_nofollow` was consolidated into `sys/fs/unix.rs::set_perm_nofollow` by rust-lang#160170, which dropped the `not(target_os = "vxworks")` guard the previous `sys/fs/mod.rs` implementation carried. VxWorks' libc defines no `O_NOFOLLOW` (the platform's `<sys/fcntlcom.h>` stops at `O_CLOEXEC`, and `rust-lang/libc` correctly does not bind it for `vxworks`), so building `std` for `x86_64-wrs-vxworks` now fails: ``` error[E0425]: cannot find value `O_NOFOLLOW` in crate `libc` --> library/std/src/sys/fs/unix.rs:1916 | | options.read(true).custom_flags(libc::O_NOFOLLOW); | ^^^^^^^^^^ not found in `libc` ``` `x86_64-wrs-vxworks` is tier 3 and isn't built in CI, so this wasn't caught. `set_perm_nofollow` is the only `O_NOFOLLOW` reference compiled for VxWorks — the `remove_dir_all` "modern" path already lists `vxworks` in its fallback set, and the remaining occurrences are a doc example and comments. Unlike ESP-IDF and Horizon (which skip `O_NOFOLLOW` because their filesystems have no symbolic links), VxWorks *does* have symlinks, so it can't just drop `O_NOFOLLOW` and follow the link silently. This returns `ErrorKind::Unsupported`, matching the existing Android stub. ## `Unsupported` is the platform-correct result Verified on-target against the shipped VxWorks 7 SDK (`wrsdk-vxworks7-qemu-1.17.0`, the QEMU BSP). VxWorks has no way to express a no-follow permission change: - No `O_NOFOLLOW`. The only related flag is `O_NOLINK` ("open the symlink itself"), which is different semantics and not what the `open` + `fchmod` path wants. - `fchmodat` *is* provided — by the UTILS_UNIX component in `libunix`, not core `libc` — and `AT_SYMLINK_NOFOLLOW` is defined as `0x100`. But the shipped `libunix.so` **rejects the flag with `ENOTSUP`**: ```asm 0000000000009300 <fchmodat>: ; (dirfd=edi, path=rsi, mode=edx, flag=ecx) cmpl $0x100,-0x18(%rbp) ; flag == AT_SYMLINK_NOFOLLOW ? jne 9340 <fchmodat+0x40> mov $0x23,%edi ; errno = 0x23 (35 = ENOTSUP) call errnoSet movl $0xffffffff,-0x4(%rbp) ; return -1 ... 9340: ; flag == 0 call taskSafe ... atCatPath(dirfd, path) call chmod ; plain chmod -> follows the symlink ``` So `fchmodat(.., AT_SYMLINK_NOFOLLOW)` returns `-1`/`ENOTSUP`, and `flag == 0` degrades to `chmod`, which follows symlinks. A `fchmodat`-based implementation is not viable on this release — the platform's own `fchmodat` reports `ENOTSUP` for exactly this request, which is why `Unsupported` is correct rather than merely conservative. cc @biabbas @hax0kartik ## Build verification On `1.100.0-nightly (9085017 2026-08-30)` + `rust-src` (stock `libc` 0.2.189): - Before: `cargo +nightly build -Zbuild-std=std,panic_abort --target x86_64-wrs-vxworks` fails with the E0425 above (1 error). - After this patch: the same command finishes successfully.
…r=jieyouxu Revert "retrieve supported GCC targets from the sysroot" see [#t-infra/bootstrap > cg_gcc sysroot?](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/cg_gcc.20sysroot.3F/with/620307625)
…wiser Prefer `LLVMGetVersion` for runtime info Our `LLVMRustVersion*` functions get hard-coded `LLVM_VERSION_*` values when we build `RustWrapper.cpp`, but this could be different than the actual LLVM library at runtime. This should never happen with toolchains from `rustup`, but with external LLVM in a distro build, for example, `rustc` and `LLVM` can be upgraded independently. Most of the time when we check the LLVM version, we're only looking at the major version anyway, and we already assert that these are equal in `configure_llvm`. However, for anything that does check the minor or patch version too, the runtime version is probably more relevant.
fix ICE in project_goals/inherent I'm a silly goose. The next solver has the exact same bug as rust-lang#161858 - merely enabling next-solver on the test added in that PR causes an ICE 🙃 ICE was technically introduced by rust-lang#161929 but this bug has always been present, it's just that PR explicitly tracked things better and ICEd on the bug instead of silently continuing. fixes rust-lang#162147 explanation: `push_const_arg_has_type_goal` expects its term to have rebased, `impl`-format args, not `Self` format args. See doc comment on `AliasConstKind::InherentSelf` for what "impl format" and "self format" mean: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/enum.AliasConstKind.html#variant.InherentSelf r? @BoxyUwU since we chatted about this yesterday but honestly anyone vaguely t-types and/or const-generics feel free to review as well, should be relatively straightforward!
…tdev Explain LoongArch f16 NaN-boxing in inline asm The psABI leaves the upper bits of a widened f16 value undefined, so the NaN-boxing here isn't ABI-required. It's intentional: it matches LLVM's own codegen and avoids an f16 value being mistaken for a valid f32 value. Update the comment to reflect this. r? @folkertdev
rustbot
added
A-compiletest
rustbot
removed
the
S-waiting-on-review
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
17 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:
forloop #161579 (suggest calling a fn item used as the iterator of aforloop)PerOwnerLoweringState#162120 (IntroducePerOwnerLoweringState)f16andf128#162151 (Test itanium mangling off16andf128)!in stability checks anymore #162162 (Don't special-case!in stability checks anymore)#[track_caller]in async #161972 (Improve tests for#[track_caller]in async)boxpattern removal diagnostic more actionable & removeboxexpression recovery #162008 (Render theboxpattern removal diagnostic more actionable & removeboxexpression recovery)libc::O_NOFOLLOWon VxWorks inset_perm_nofollow#162065 (std: don't referencelibc::O_NOFOLLOWon VxWorks inset_perm_nofollow)LLVMGetVersionfor runtime info #162153 (PreferLLVMGetVersionfor runtime info)r? @ghost
Create a similar rollup