Rollup of 12 pull requests - #162254
Merged
Merged
Conversation
Commit bd174e1 ("Implement clamp_to") added a few float methods that are not marked `#[inline]`. This causes `core` to require new symbols in soft-float builds, even if the methods are unused, e.g. from the Linux kernel: ld.lld: error: undefined symbol: fmaximum_numf >>> referenced by core.1f440ee8661e09f9-cgu.0 >>> rust/core.o:(<core::ops::range::RangeFrom<f32> as core::cmp::clamp::ClampBounds<f32>>::clamp) in archive vmlinux.a (and similar for `f{min,max}imum_num{f,}` and `__gt{s,d}f2`). It is possible to work around this in the Linux side, but these methods should probably be `#[inline]` to begin with, like many other similar methods are. Thus mark them as inline. Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
…hecked_math.rs Otherwise e.g. `@unchecked_add_unsigned` and `@unchecked_add_signed` get merged after llvm/llvm-project#220015, breaking the test's expectations.
Get the NT path then search for a drive that links to a prefix of it.
implement `Add` and `Sub` for `Complex` tracking issue: rust-lang#154023 Adds the `Add` and `Sub` implementations described in the tracking issue. Some notes - I also added a derive for `Eq`, which is useful for `Complex<{integer}>` - The versions that add/sub by a scalar need a `Copy` bound. That seems fine for most actual use cases. Apparently `num_complex` will `Clone` in these operations https://docs.rs/num-complex/latest/num_complex/struct.Complex.html#impl-Add%3CT%3E-for-%26Complex%3CT%3E, but that seems unlike `core` to me. Anyhow, libs can re-litigate that later.
…re-arm, r=davidtwco make target feature ABI check a hard error on ARM With LLVM 24, we now (finally) get hard errors from the backend for "you want ABI X but the target features required for that ABI are missing", at least on the ARM backend: ``` error: <unknown>:0:0: in function _RNvXsc_Cs4Af2OiBEA1T_8minicoreiNtB5_3Add3add i32 (i32, i32): calling convention is hard-float, but floating-point registers are unavailable ``` That's not a pretty error, so let's make rust emit a hard error before we even get there -- just on ARM for now, matching LLVM. We have emitted a future-compat error for this since Rust 1.86 (rust-lang#136147, rust-lang#134794). I'm not making it a hard error everywhere since for other targets we are still figuring out the exact things we have to check, and it's better to do that without risking new hard errors. For ARM, the exact check we are doing is: - every target must set `llvm_floatabi` to either "soft" or "hard" - on softfloat targets, no check is needed - on hardfloat targets, the "fpregs" target feature is *required* and the the "soft-float" target feature is *forbidden* Since this is a new hard error, this probably requires FCP. I am not sure for which team -- @rust-lang/lang is often involved for target feature things, but this is mostly about rejecting invalid `-C` flags which are handled by t-compiler (@davidtwco @BoxyUwU). Fixes rust-lang#161276 Tracking issue rust-lang#116344 Cc @TimNN
Add custom allocator support to `(try_)map` on `UniqueArc` and `UniqueRc` Follow-up to rust-lang#161617. This one required me to add allocator support to a lot more methods. Probably good for them to have it for future additions ^^ The old, allocator-free methods went unused from this change and I had to remove them because we don't allow warnings (they are trivial to implement on top of the allocator ones). This had the side effect of making the diff a bit weird. Sorry! r? nia-e
…closure-debug, r=spastorino fix[154166]: closure debug capture print Found and remove the `// FIXME(project-rfc-2229#48)` [see](rust-lang/rfcs#2229) in `mir/pretty.rs` used to Debug print mir. Fix was to replace the old `tcx.upvars_mentioned` with `tcx.closure_captures`. Added a test to check for printing of both in 2018 and 2021
… r=clarfonthey Windows: add fallback if `canonicalize` fails This attempts a partial workaround for issues such as: rust-lang#59392, rust-lang#79449, rust-lang#59107, rust-lang#54875, rust-lang#52440, rust-lang#52377, rust-lang#48249, rust-lang#74327, rust-lang#55812 This may require a bit of explanation depending on how familiar you are with Windows paths, I'll try to keep it brief. The short version is that the above issues are cases where third party devices don't integrate with the system sufficiently so Windows isn't aware of the canonical drive for a particular path, causing our `canonicalize` function to fail. This PR works around it by manually search for the drive letter that corresponds to the root of the path. This only works in cases where there is a drive letter assigned but that is the majority of cases. It won't work when the device is only mounted to a directory in another filesystem or isn't mounted at all. To explain the implementation of this PR you should be aware that Windows on Windows NT is more like WINE on Linux then many people realise. You have a kernel (NT) and then you have an implementation of the Win32 APIs on top (this is why `kernel32.dll` is nothing to do with the real kernel, it's like an implementation of Win95's kernel API on top of another OS). Admittedly the boundaries have become fuzzier over the years but there still remains a clear distinction between the Win32 API and the NT kernel API in many places. Paths are one place where this distinction is made clear. You have the familiar Win32 paths like `C:\path\to\file` that date back to the time of DOS. And then you have the low-level NT kernel paths that look like `\Device\HarddiskVolume6\path\to\file` (which aren't really meant to be user-visible). To bridge the gap, the NT namespace has a special `??` directory containing mappings (i.e. symlinks) from drives like `C:` to paths like `\Device\HarddiskVolume6`. In that way translating between Win32 and NT paths is made simpler as you can replace `C:` with `\??\C:` and it'll get resolved to the right path and vice versa (the actual translation from win32 to NT is more complicated but I've already spent too many words on this). So back to canonicalisation. Resolving the canonical NT path should always succeed. The problem comes when mapping that to a Win32 drive path. When the drive is managed by the system then when resolving paths it knows which drive to pick. However, if the drive mapping is added manually then it doesn't. So the way to workaround this is to manually look at the drive mappings and see which one is the root of the NT path we have.
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
remove outdated next-solver handling see inline comments
core: mark float `ClampBounds` methods as `#[inline]` Commit bd174e1 ("Implement clamp_to") added a few float methods that are not marked `#[inline]`. This causes `core` to require new symbols in soft-float builds, even if the methods are unused, e.g. from the Linux kernel: ld.lld: error: undefined symbol: fmaximum_numf >>> referenced by core.1f440ee8661e09f9-cgu.0 >>> rust/core.o:(<core::ops::range::RangeFrom<f32> as core::cmp::clamp::ClampBounds<f32>>::clamp) in archive vmlinux.a (and similar for `f{min,max}imum_num{f,}` and `__gt{s,d}f2`). It is possible to work around this in the Linux side, but these methods should probably be `#[inline]` to begin with, like many other similar methods are. Thus mark them as inline.
…ds, r=jhpratt docs(time): clarify exact seconds for week and day Documented that `Duration::from_weeks` defines one week as 604,800 seconds (7 days), and `Duration::from_days` defines one day as 86,400 seconds (24 hours). Doctests for these methods also appear to be based on these definitions. The purpose of this is to clarify that `Duration` is a fixed length value that ignores factors such as DST or a leap second. This is inspired by <rust-lang/libs-team#869 (comment)>. See also rust-lang#120301 @rustbot label +A-docs
…conds, r=jhpratt docs(time): clarify exact seconds for hour and minute Documented that `Duration::from_hours` defines one hour as 3,600 seconds (60 minutes), and `Duration::from_mins` defines one minute as 60 seconds. Doctests for these methods also appear to be based on these definitions. The purpose of this is to clarify that `Duration` is a fixed length value that ignores factors such as a leap second. This is inspired by <rust-lang/libs-team#869 (comment)>. It seems that no library in Rust handle leap seconds, so there isn't much point in documenting this. However, I don't think it would hurt to include it for the sake of consistency with rust-lang#162195. See also rust-lang#120301 @rustbot label +A-docs
…ercote coverage: Small cleanups in `extract_hir_info` Two small improvements that I noticed while contemplating follow-ups to rust-lang#161517. - Using a recursive call to modify function arguments is cute but confusing. - Using a single deeply-nested pattern ends up being less readable than a multi-step let-chain. There should be no change to compiler output.
Pass -Z merge-functions=disabled in tests/codegen-llvm/intrinsics/unchecked_math.rs Otherwise e.g. `@unchecked_add_unsigned` and `@unchecked_add_signed` get merged after llvm/llvm-project#220015, breaking the test's expectations.
rustbot
added
O-windows
rust-bors
Bot
added
S-waiting-on-author
Contributor
|
💔 Test for f1d4ce8 failed: CI. Failed job:
|
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Contributor
|
Opened a PR to fix CI by adding a lockfile to the test in question: #162265 |
This was referenced Sep 4, 2026
Member
|
I think the new tinyvec version resolves the problem, let's see |
Member
|
@bors retry |
rust-bors
Bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
rust-bors
Bot
added
merged-by-bors
Contributor
This was referenced Sep 4, 2026
Contributor
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing a69a632 (parent) -> 71238e2 (this PR) Test differencesShow 209 test diffsStage 1
Stage 2
Additionally, 194 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 71238e21fc55e73ab3aad8c9f79fed7a47a179e1 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Member
Author
|
@bors treeopen |
Contributor
|
Tree is now open for merging. |
Collaborator
|
Finished benchmarking commit (71238e2): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -2.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary 2.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 476.914s -> 475.37s (-0.32%) |
Contributor
|
📌 Perf builds for each rolled up PR:
parent commit: a69a63265c In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
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.
View all comments
Successful merges:
AddandSubforComplex#161227 (implementAddandSubforComplex)(try_)maponUniqueArcandUniqueRc#161893 (Add custom allocator support to(try_)maponUniqueArcandUniqueRc)canonicalizefails #161951 (Windows: add fallback ifcanonicalizefails)bug!being reachable #162173 (fix supposedly unreachablebug!being reachable)ClampBoundsmethods as#[inline]#162191 (core: mark floatClampBoundsmethods as#[inline])extract_hir_info#162222 (coverage: Small cleanups inextract_hir_info)r? @ghost
Create a similar rollup