Rollup of 18 pull requests - #162189
Closed
Zalathar wants to merge 52 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.
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.
because "g" is used for __ibm128, __float128 gets a custom name
Co-authored-by: mejrs <59372212+mejrs@users.noreply.github.com>
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.
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
fix supposedly unreachable `bug!` being reachable `bug!` introduced in rust-lang#161929 fixes rust-lang#162146 wfcheck.rs does a normalize on a type here https://github.com/rust-lang/rust/blob/edc52f87c28f328c61685a02c47887a5cec7d767/compiler/rustc_hir_analysis/src/check/wfcheck.rs#L929 which reduces the contained alias within from a nonrigid InherentSelf to a rigid InherentImpl, because we do so upon encountering a too-generic-to-ctfe alias the very next line, it then `register_wf_obligation` on the resulting normalized type, that contains an InherentImpl inside wf, that eventually hits the `bug!` I added and ICEs https://github.com/rust-lang/rust/blob/a4330234a776684c36428d001721d0320d24dd77/compiler/rustc_trait_selection/src/traits/wf.rs#L1104 r? @BoxyUwU
rustbot
added
A-compiletest
Member
Author
|
This rollup is mainly for running advance try jobs, but I'll also put it in the queue at low-priority to make it more visible. @bors r+ rollup=never p=0 |
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 2, 2026
Rollup of 18 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-1 try-job: aarch64-apple-2 try-job: x86_64-mingw-1 try-job: i686-msvc-1 try-job: i686-msvc-2
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
rust-bors
Bot
added
S-waiting-on-author
Contributor
|
PR #161694, which is a member of this rollup, was unapproved. This rollup was thus unapproved. |
rustbot
removed
the
S-waiting-on-author
rust-bors
Bot
added
the
S-waiting-on-author
Contributor
|
💔 Test for 49eb92f failed: CI. Failed jobs:
|
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)ComplexABI run-make test #161694 (addComplexABI run-make test)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)impl TryFrom<int> for int#162076 (docs(num): clarify conditions under which error occurs inimpl TryFrom<int> for int)LLVMGetVersionfor runtime info #162153 (PreferLLVMGetVersionfor runtime info)bug!being reachable #162173 (fix supposedly unreachablebug!being reachable)r? @ghost
Create a similar rollup