Skip to content

Rollup of 15 pull requests - #150229

Closed
JonathanBrouwer wants to merge 33 commits into
rust-lang:mainfrom
JonathanBrouwer:rollup-thxbx6i
Closed

Rollup of 15 pull requests#150229
JonathanBrouwer wants to merge 33 commits into
rust-lang:mainfrom
JonathanBrouwer:rollup-thxbx6i

Conversation

@JonathanBrouwer

@JonathanBrouwerJonathanBrouwer commented Dec 21, 2025

Copy link
Copy Markdown
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

fmeaseand others added 30 commits November 26, 2025 04:57
Signed-off-by: tison <wander4096@gmail.com>
Fixes library linking issues where libgcc_s was incorrectly being linked
instead of the appropriate LLVM runtime libraries for Hexagon targets.
* Set llvm-libunwind as default for all hexagon targets in bootstrap
* Exclude hexagon from automatic libgcc_s linking in unwind
* Enable libunwind.a copying for hexagon targets
* Remove manual library linking from hexagon target specification
If we convert the minimum length to `u64` up-front when creating
`TestableCase::Slice`, we can avoid more conversions to `u64` later.
This was accidentally added to the prelude in
3f4dc1e.
Don't strip shebang in expr-ctxt `include!(…)`
No longer strip shebang interpreter directives in files that were `include`d in expression (statement) contexts.
…-fix, r=Amanieu
Fix d32 usage in Arm target specs
Fixesrust-lang#149399 - after checking with an LLVM engineer Rust's feature implications do correctly map to LLVM's. The target specs originally had +vfp3,+d16, but were mistakenly fixed to +vfp3,-d32 which disables vfp3 again.
Some targets specify +vfp2,-d32, and since vfp2 shouldn't imply d32 the -d32 is unneeded.
The list of Arm features is quite old and since Arm is now a target maintainer of many of them we'll go in and update them. We should probably add vfp3d16 and similar as rust has no way to express these right now after d16 was removed.
The LLVM features expand like this:
```
vfp4 -> vfp3 + fp16 + vfp4d16 + vfp4sp
vfp4d16 -> vfp3d16 + fp16 + fp64 + vfp4d16sp
vfp4sp -> vfp3sp + fp16 + d32 + vfp4d16sp
vfp4d16sp -> vfp3d16sp + fp16
vfp3 -> vfp2 + vfp3d16 + vfp3sp
vfp3d16 -> vfp2 + fp64 + vfp3d16sp
vfp3sp -> vfp2 + d32 + vfp3d16sp
vfp3d16sp -> vfp2sp
vfp2 -> vfp2sp + fp64
vfp2sp -> fpregs
```
`-neon` might be unnecessary too in many of these cases, but some default CPUs that Rust specifies will turn Neon on so that needs a bit more care. I can't see any LLVM cpus that enable D32.
Old description:
> Fixesrust-lang#149399 - this implication was likely a mistake and isn't enforced by LLVM. This is is a breaking change and any users specifying `vfp2/3/4` via `-Ctarget-features` or the `target_feature` attribute will need to add `d32` in to get the same behaviour. The target features are unstable so this is ok for Rust, and this is necessary as otherwise there's no way to specify a `vfp2-d16` configuration, for example.
>
> I expect these targets would have been broken by rust-lang#149173 as `-d32` would have disabled any `+vfpX` feature before it. With the removal of the implication the `-d32` went back to being unnecessary, but I've removed it anyway.
>
> As `@RalfJung` pointed out, thumbv7a-nuttx-eabihf looks to have been relying on this implication so I've added `+d32` to it's target spec.
…=Mark-Simulacrum
Add const default for OnceCell and OnceLock
cc rust-lang#143894
…mulacrum
miri: add -Zbinary-dep-depinfo to dependency builds
Hopefully fixesrust-lang#149711
Cc `````@bjorn3`````
…-Simulacrum
Enable llvm-libunwind by default for Hexagon targets
Fixes library linking issues where libgcc_s was incorrectly being linked instead of the appropriate LLVM runtime libraries for Hexagon targets.
* Set llvm-libunwind as default for all hexagon targets in bootstrap
* Exclude hexagon from automatic libgcc_s linking in unwind
* Enable libunwind.a copying for hexagon targets
* Remove manual library linking from hexagon target specification
fix docustring on fetch_or
The documentation had the same example twice in a row, but I think this was the intended second example.
tests/ui/traits/fmt-pointer-trait.rs: Add HRTB fn pointer case
Closesrust-lang#50280 which just **E-needs-test**. See rust-lang#50280 (comment) for a bisect of the fix.
The issue description is quite vague, so in the test I am linking directly to the most descriptive comment rust-lang#50280 (comment).
mir_build: Use the same length type for `TestableCase::Slice` and `TestKind::Len`
If we convert the minimum length to `u64` up-front when creating `TestableCase::Slice`, we can avoid more conversions to `u64` later.
There should be no change to compiler behaviour.
…reexport, r=GuillaumeGomez
[rustdoc] Add missing close tags in extern crate reexports
Fixesrust-lang#150176
change non-canonical clone impl to {*self}, fix some doc comments
…om-prelude, r=jdonszelmann
Drop the From derive macro from the v1 prelude
This was accidentally added to the prelude in 3f4dc1e.
Fixes: rust-lang#150165
r? ``````@jdonszelmann``````
tests/debuginfo/function-arg-initialization.rs: Stop disabling SingleUseConsts MIR pass
This test passes locally for me. Let's see if it passes CI too.
Discovered while I worked on rust-lang#150201.
CC rust-lang#128945
…ease
rustdoc: handle macro expansions in types
- Closesrust-lang#150154.
- Closesrust-lang#150197.
This PR implements `visit_ty` in `ExpandedCodeVisitor` to correctly handle macro expansions in type positions (e.g., `let _: foo!();`). This also fixes a crash in rustdoc caused by the same issue.
Before:
<img width="419" height="182" alt="image" src="https://github.com/user-attachments/assets/89627230-032d-4ba1-af2e-8aa9a9cc6627" />
After:
<img width="288" height="107" alt="image" src="https://github.com/user-attachments/assets/c06caeda-28b7-45b8-845a-e7fe784a82e4" />
GVN: Adds the `insert_unique` method
The new `insert_unique` method is used to handle `IndexVec<VnIndex, T>` such as `evaluated` and `rev_locals`.
@rustbotrustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-clippy Relevant to the Clippy team. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. rollup A PR which is a rollup labels Dec 21, 2025
@JonathanBrouwer

Copy link
Copy Markdown
MemberAuthor

@bors r+ rollup=never p=5

@bors

bors commented Dec 21, 2025

Copy link
Copy Markdown
Collaborator

📌 Commit 036831e has been approved by JonathanBrouwer

It is now in the queue for this repository.

@borsbors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 21, 2025
@JonathanBrouwer
JonathanBrouwer deleted the rollup-thxbx6i branch August 21, 2026 08:30
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

rollupA PR which is a rollupS-waiting-on-borsStatus: Waiting on bors to run and complete tests. Bors will change the label on completion.T-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)T-clippyRelevant to the Clippy team.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.T-libsRelevant to the library team, which will review and decide on the PR/issue.T-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.T-rustdoc-frontendRelevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

16 participants

@JonathanBrouwer@bors@rustbot@fmease@adamgemmell@tisonkun@RalfJung@androm3da@agavra@jdonszelmann@Zalathar@hkBst@jtgeibel@Enselic@dianqk@el-ev