Jieyou Xu
8d58d5e800
Remove run-make-support CHANGELOG
...
Hopelessly outdated, and this support library is purely internal.
2025-07-09 20:02:36 +08:00
bors
d350797b7e
Auto merge of #142707 - ashivaram23:drop_wildcard, r=dianqk
...
Apply effects to `otherwise` edge in dataflow analysis
This allows `ElaborateDrops` to remove drops when a `match` wildcard arm covers multiple no-Drop enum variants. It modifies dataflow analysis to update the `MaybeUninitializedPlaces` and `MaybeInitializedPlaces` data for a block reached through an `otherwise` edge.
Fixes rust-lang/rust#142705 .
2025-07-09 03:42:01 +00:00
Amogh Shivaram
c7ef03aeb7
Apply effects to otherwise edge in dataflow analysis
2025-07-08 18:15:05 -05:00
bors
34097a38af
Auto merge of #140525 - lqd:stabilize-lld, r=petrochenkov
...
Use lld by default on `x86_64-unknown-linux-gnu` stable
This PR and stabilization report is joint work with `@Kobzol.`
#### Use LLD on `x86_64-unknown-linux-gnu` by default, and stabilize `-Clinker-features=-lld` and `-Clink-self-contained=-linker`
This PR proposes making LLD the default linker on the `x86_64-unknown-linux-gnu` target for the artifacts we distribute, and also stabilizing the `-Clinker-features=-lld` and `-Clink-self-contained=-linker` codegen options to make it possible to opt out.
LLD has been used as the default linker on nightly and CI on this target since May 2024 ([PR](https://github.com/rust-lang/rust/pull/124129 ), [blog post](https://blog.rust-lang.org/2024/05/17/enabling-rust-lld-on-linux.html )), and it seems like it is working fine, so we would like to propose stabilizing it.
The main motivation for using LLD instead of the default BFD linker is improving [compilation times](https://perf.rust-lang.org/compare.html?start=b3e117044c7f707293edc040edb93e7ec5f7040a&end=baed03c51a68376c1789cc373581eea0daf89967&stat=instructions%3Au&tab=compile ). For example, in the linked benchmark, it makes incremental recompilation of `ripgrep` in `debug` more than twice faster. Another benefit is that Rust compilation becomes more consistent and self-contained, because we will use a known version of the LLD linker, rather than "whatever GNU ld version is on the user's system".
Due to the performance benefit being so huge, many people already opt into using LLD (or other fast linkers, such as mold) using various approaches ([1](https://github.com/search?type=code&q=%2Flinker-flavor%5B%3D+%5Dgnu-lld-cc%2F ), [2](https://github.com/search?type=code&q=%2Flinker-features%5B%3D+%5D%5C%2Blld%2F ), [3](https://github.com/search?type=code&q=language%3Atoml+%22-fuse-ld%3Dlld%22 ), [4](https://github.com/search?type=code&q=language%3Arust+%22-fuse-ld%3Dlld%22 )). By making LLD the default linker on the `x86_64-unknown-linux-gnu` target, we will be able to speed up Rust compilation out of the box, without users having to opt in or know about it.
> You can find an extended version of this stabilization report which includes analysis of crater results and more data [here](https://hackmd.io/tFDifkUcSLGoHPBRIl0z8w?view ).
## What is being stabilized
- `rust-lld` being used as the default linker on the `x86_64-unknown-linux-gnu` target.
- Note that `rust-lld` is being enabled by default in the compiler artifacts distributed by our CI/rustup. It is still possible to use the system linker by default using `rust.lld = false` in `bootstrap.toml`, which can be useful e.g. for some Linux distros that might not want to use the LLD we distribute.
- This is done by activating the LLD linker feature and using the self-contained linker on that target. Both of which are also usable on the CLI, if some opt outs are necessary, as described below.
- `-Clinker-features=-lld` on the `x86_64-unknown-linux-gnu` target. This codegen option tells rustc to disable using the LLD linker.
- Note that other options for this codegen flag (`cc`) remain unstable.
- Note that only the opt-out is being stabilized, and only for `x86_64-unknown-linux-gnu`: opting in, or using the flag on other targets would still need to pass `-Zunstable-options`.
- This flag is being stabilized so that users can opt out of LLD on stable, which would it turn also opt out of using the self-contained linker (since it's an LLD).
- `-Clink-self-contained=-linker`. This codegen option tells rustc to use the self-contained linker. It's not particularly useful to turn it on by itself, but when enabled and combined with `-Clinker-features=+lld`, rustc will use the `rust-lld` linker wrapper shipped with the compiler toolchain, instead of some `lld` binary that the linker driver will find in the `PATH`.
- Note that other options for this codegen flag (other than the previously stable `y/yes/n/no`).
- Note that only the opt-out is being stabilized, and only for `x86_64-unknown-linux-gnu`: opting in, or using this flag on other targets would still need to pass `-Zunstable-options`.
- This flag is being stabilized so that users can opt out of using self-contained linking on stable. Doing this would then fall back to using the system `lld`.
To opt out of using LLD, `RUSTFLAGS="-Clinker-features=-lld"` would be used. To opt out of using `rust-lld`, falling back to the LLD installed on the system, `RUSTFLAGS="-Clink-self-contained=-linker"` would be used.
## Tests
When enabling `rust-lld` on nightly, we also switched x64 linux to use it at stage >= 1, meaning that all tests have been running with lld since May 2024, on CI as well as contributors' machines. (Post opt-dist tests also had been using it when running their test subset earlier than that).
There are also a few tests dedicated to the CLI behavior, or ensuring the default linker is indeed the one we expect:
- [link-self-contained-consistency](1117bc1e6c/tests/ui/linking/link-self-contained-consistency.rs1117bc1e6c/tests/ui/linking/link-self-contained-unstable.rs1117bc1e6c/tests/ui/linking/linker-features-unstable-cc.rs1117bc1e6c/tests/ui/linking/linker-features-lld-disallowed.rs1117bc1e6c/tests/ui/linking/link-self-contained-linker-disallowed.rs1117bc1e6c/tests/ui/linking/no-gc-encapsulation-symbols.rshttps://github.com/dtolnay/linkme ) still work.
- [rust-lld](1117bc1e6c/tests/run-make/rust-lld1117bc1e6c/tests/run-make/rust-lld-x86_64-unknown-linux-gnu1117bc1e6c/tests/run-make/rust-lld-x86_64-unknown-linux-gnu-disthttps://crater-reports.s3.amazonaws.com/pr-117684-2/index.html ), [February 2025](https://crater-reports.s3.amazonaws.com/pr-137044-3/index.html )), were performed to test the impact of using LLD as the default linker. A triage of the earlier crater run was previously done [here](https://hackmd.io/OAJxlxc6Te6YUot9ftYSKQ ), but all the important findings from both crater runs are reported below.
Below is a list of compatibility differences between BFD and LLD that we have encountered. There is a more thorough list of differences in [this post](https://maskray.me/blog/2020-12-19-lld-and-gnu-linker-incompatibilities ) from the current LLD maintainer. From that post, "99.9% pieces of software work with ld.lld without a change".
---
### `.ctors/.dtors` sections
[#128286 ](https://github.com/rust-lang/rust/issues/128286 ) reported an issue where LLD was unable to link certain CUDA library was using these sections that were using the `.ctors/.dtors` ELF sections. These were deprecated a long time ago (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 ), replaced with a more modern `.init_array/.fini_array` sections. LLD doesn't (and won't) support these sections ([1](https://github.com/llvm/llvm-project/issues/68071 ), [2](https://github.com/llvm/llvm-project/issues/30572 )), so if they appear in input object files, the linked artifact might produce incorrect behavior, because e.g. some global variables might not get initialized properly.
However, the usage of `.ctors/.dtors` should be very rare in practice. We have performed a [crater run](https://github.com/rust-lang/rust/pull/137044 ) to test this. It has identified only 8 crates where the `.ctors/.dtors` section is occurring in the final linked artifact. It was caused by a few crates using the `.ctors` link section manually, and by using a very (~6 year) old version of the [ctor](https://crates.io/crates/ctor ) crate.
[Crater run analysis](https://hackmd.io/tFDifkUcSLGoHPBRIl0z8w?view#ctorsdtors-sections )
**Possible workaround**
It is possible to [detect](e5e2316712https://github.com/rust-lang/rust/pull/112049#issuecomment-2661125340 ). We have benchmarked the check on a 240 MiB Chrome binary, where it took 0.8ms with page cache flushed, and 0.06ms with page cache primed (which should be the common case, as the linked artifact is written to disk just before the check is performed).
In theory, this could be also solved with a linker script that moves `.ctors` to `.init_array`.
We think that these sections should be so rare that it is not worth it to implement any workarounds for now.
---
### Different garbage collection behavior
[#130397 ](https://github.com/rust-lang/rust/issues/130397 ) reported an issue where LLD prunes a local symbol, so it is missing in the linked artifact. However, BFD keeps the same symbol, so it is a regression. This is caused by a difference in linker garbage collection.
Rust uses `--gc-sections` and puts each function into a separate linker section, which prunes unused code. There is some code (specifically the somewhat popular [linkme](https://github.com/dtolnay/linkme ) crate) that (arguably ab-)uses so called linker encapsulation symbols to achieve distributed slices.
BFD (2.37+) uses a conservative linking mode that works as intended with this behavior, but it might slightly increase binary size of the linked artifact. LLD does not use this workaround by default, which causes the sections to be eliminated, but it can be made to use the conservative mode using [`-z nostart-stop-gc`](https://lld.llvm.org/ELF/start-stop-gc.html#z-start-stop-gc ).
To avoid this issue, we told LLD to use the [conservative mode](https://github.com/rust-lang/rust/pull/137685 ), which maintains backwards compatibility with BFD. We found that it has [no effect](https://github.com/rust-lang/rust/pull/112049#issuecomment-2666028775 ) on compilation performance and binary size in our benchmark suite. With this change, `linkme` works. Since then, rust-lang/rust#140872 removed `linkme` distributed slice's dependence on conservative GC behavior, so this PR also removes that conservative mode: no transition period is necessary, as the PR immediately fixed the crate with no source changes.
[Crater run analysis](https://hackmd.io/tFDifkUcSLGoHPBRIl0z8w?view#Different-garbage-collection-behavior )
---
### Various uncommon issues
A small number of issues that only occurred in a handful of instances were found in crater, and it is unclear if LLD is at fault or if there is some other issue that was not detected with BFD.
You can examine these [here](https://hackmd.io/tFDifkUcSLGoHPBRIl0z8w?view#Various-uncommon-issues ).
---
### Missing jobserver support
LLD doesn't support the jobserver protocol for limiting the number of threads used, it simply defaults to using all available cores, and is one of the reasons why it's faster than BFD. However, this should mostly be a non-issue, because most of the linking done during high parallelism sections of `cargo build` is linking of build scripts and proc macros, which are typically very fast to link (e.g. ~50ms), and a potential oversubscription of cores thus doesn't hurt that much.
When the final artifact is linked (which typically takes the most time), there should be no other sources of parallelism conflicts from compiling other code, so LLD should be able to use all available threads.
That being said, it is a difference of behavior, where previously a `-j` flag was generally not using more cpu than the specified limit. It can be impactful in some resource-constrained systems, but to be clear that is already the case today due to [cargo parallelism](https://github.com/rust-lang/cargo/issues/9157 ). This could be one reason to opt out of using `rust-lld` on some systems.
LLD has support for limiting the number of threads to use, so in theory rustc could try to get all the jobserver tokens available and use that as lld's thread limit. It'd still be suboptimal as new tokens would not be dynamically detected, and we could be using less threads than available.
We did a benchmark on a real-world crate that shows that using multiple LLD threads for intermediate artifacts doesn't seem to have a performance effect. You can find it [here](https://hackmd.io/tFDifkUcSLGoHPBRIl0z8w?view#Missing-jobserver-support ).
---
#### Opting out of LLD in the ecosystem
We have also examined repositories where people opted out of LLD on nightly, using [this GitHub query](https://github.com/search?q=%22linker-features%3D-lld%22&type=code ). The summary can be found below:
<details>
<summary>Summary of LLD opt outs</summary>
> This examination was performed on 2025-03-09.
Here we briefly examine the most common reasons why people use `-Zlinker-features=-lld`, based on comments and git history.
- Nix/NixOS ([1](59d703dff5/flake.nix (L33)3cc3449fc1/.cargo/config.toml (L4)https://github.com/tiiuae/ebpf-firewall/blame/32bdb17cedd1c9bea1ab3482623de458d95da7d0/.cargo/config.toml#L2 ), [4](f5f657d014/Cargo.toml (L4)e4266f5c55/.cargo/config.toml (L10)22a4aef24e/README.md (L78)2222d53474/.cargo/config.toml (L2)b2ffa59d3e/.cargo/config.toml (L4)3ead4ef9c7/.cargo/config.toml (L2)ca6b8c8a5d/work/examples/lsp-client/src/extension.ts (L94)https://github.com/NixOS/nixpkgs/issues/312661 ) with LLD, which seems to have been fixed with https://github.com/NixOS/nixpkgs/pull/314268 .
It's unclear whether that fixed all the Nix issues though.
- Issues with linkme ([1](ef388619ff/.cargo/config.toml (L4)be0fc5827f/README.md (L20)c5d8444d56/rust/.cargo/config.toml (L6)5b4cc1a519/.cargo/config.toml (L3)4e27c7de2a/.github/workflows/ci.yml (L82)8fe60c12bc/.github/workflows/code-coverage.yml (L48)c8b4683798/.github/workflows/ci.yml (L74)#137685 ](https://github.com/rust-lang/rust/pull/137685 )).
- Bazel ([1](1823f69ed8/.bazelrc (L71)ca6b8c8a5d/work/examples/wasm-build.sh (L37)2bf99037ca/build.sh (L21)5118be6b9e/.cargo/config.toml (L3)https://github.com/Wyvern/Img/blame/45020c7e1dc4926c8129647014c708db0c13f463/.cargo/config.toml#L209 ), [4](042eb835f7/README.md (L89)fd0b300676/exercises/.cargo/config.toml (L13)be65f2ec92/.github/workflows/rust.yml (L20)#39915 ](https://github.com/rust-lang/rust/issues/39915 ), [#71515 ](https://github.com/rust-lang/rust/issues/71515 )). There were [very early attempts](https://github.com/rust-lang/rust/pull/29974 ) to use the gold linker by default, but these had to be [reverted](https://github.com/rust-lang/rust/pull/30913 ) because of compatibility issues. Support for LLD was implemented back in [2017](https://github.com/rust-lang/rust/pull/40018 ), but it has not been made default yet, except for some more niche targets, such as [WASM](https://github.com/rust-lang/rust/pull/48125 ), [ARM Cortex](https://github.com/rust-lang/rust/pull/53648 ) or [RISC-V](https://github.com/rust-lang/rust/pull/53822 ).
It took quite some time to figure out how should the interface for selecting the linker (and the way it is invoked) look like, as it differs a lot between different platforms, linkers and compiler drivers. During that time, LLD has matured and achieved [almost perfect compatibility](https://maskray.me/blog/2020-12-19-lld-and-gnu-linker-incompatibilities ) with the default Linux linker (BFD).
- [#56351 ](https://github.com/rust-lang/rust/pull/56351 ) stabilized `-Clinker-flavor`, which is used to determine how to invoke the linker. It is especially useful on targets where selecting the linker directly with `-Clinker` is not possible or is impractical.
- December 2018, author `@davidtwco,` reviewer `@nagisa`
- [#76158 ](https://github.com/rust-lang/rust/pull/76158 ) stabilized `-Clink-self-contained=[y|n]`, which allows overriding the compiler's heuristic for deciding whether it should use self-contained or external tools (linker, sanitizers, libc, etc.). It only allowed using the self-contained mode either for everything (`y`) or nothing (`n`), but did not allow granular choice.
- September 2020, author `@mati864,` reviewer `@petrochenkov`
- [#85961 ](https://github.com/rust-lang/rust/pull/85961 ) implemented the `-Zgcc-ld` flag, which was a hacky way of opting into LLD usage.
- June 2021, author `@sledgehammervampire,` reviewer `@petrochenkov`
- [MCP 510](https://github.com/rust-lang/compiler-team/issues/510 ) proposed stabilizing the behavior of `-Zgcc-ld` using more granular flags (`-Clink-self-contained=linker -Clinker-flavor=gcc-lld`).
- Initially implemented in [#96827 ](https://github.com/rust-lang/rust/pull/96827 ), but `@petrochenkov` [suggested](https://github.com/rust-lang/rust/pull/96827#issuecomment-1208441595 ) a slightly different approach.
- The PR was split into [#96884 ](https://github.com/rust-lang/rust/pull/96884 ), where it was decided what will be the individual components of `-Clink-self-contained=linker`.
- And [#96401 ](https://github.com/rust-lang/rust/pull/96401 ), which implemented the `-Clinker-flavor` part.
- The MCP was finally implemented in [#112910 ](https://github.com/rust-lang/rust/pull/112910 ).
- [#116514 ](https://github.com/rust-lang/rust/pull/116514 ) then removed `-Zgcc-ld`, as it was replaced by `-Clinker-flavor=gnu-lld-cc` + `-Clink-self-contained=linker`.
- April 2022 - October 2023, author `@lqd,` reviewer `@petrochenkov`
- Various linker handling refactorings were performed in the meantime: [#97375 ](https://github.com/rust-lang/rust/pull/97375 ), [#98212 ](https://github.com/rust-lang/rust/pull/98212 ), [#100126 ](https://github.com/rust-lang/rust/pull/100126 ), [#100552 ](https://github.com/rust-lang/rust/pull/100552 ), [#102836 ](https://github.com/rust-lang/rust/pull/102836 ), [#110807 ](https://github.com/rust-lang/rust/pull/110807 ), [#101988 ](https://github.com/rust-lang/rust/pull/101988 ), [#116515 ](https://github.com/rust-lang/rust/pull/116515 )
- The implementation of linker flavors with LLD was causing a sort of a combinatorial explosion of various options.
[#119906 ](https://github.com/rust-lang/rust/pull/119906 ) suggested a different approach for linker flavors (described [here](https://github.com/rust-lang/rust/pull/119906#issuecomment-1894088306 )), where the individual flavors could be enabled separately using `+/-` (e.g. `+lld`).
- After some back and forth, this idea was moved to `-Clinker-features` (see [comment 1](https://github.com/rust-lang/rust/pull/119906#issuecomment-1895693162 ) and [comment 2](https://github.com/rust-lang/rust/pull/119906#issuecomment-1980801438 )), which was implemented in [#123656 ](https://github.com/rust-lang/rust/pull/123656 ).
- April 2024, author `@lqd,` reviewer `@petrochenkov`
- [#124129 ](https://github.com/rust-lang/rust/pull/124129 ) enabled LLD by default on nightly.
- April 2024, author `@lqd,` reviewer `@petrochenkov`
- [#137685 ](https://github.com/rust-lang/rust/pull/137685 ), [#137926 ](https://github.com/rust-lang/rust/pull/137926 ) enabled the conservative gargage collection mode (`-znostart-stop-gc`) to improve compatibility with BFD.
- February 2025, author `@lqd,` reviewer `@petrochenkov` (implementation), author `@kobzol,` reviewer `@lqd` (test)
- [#96025 ](https://github.com/rust-lang/rust/pull/96025 ) (April 2022), [#117684 ](https://github.com/rust-lang/rust/pull/117684 ) (November 2023), [#137044 ](https://github.com/rust-lang/rust/pull/137044 ) (February 2025): crater runs.
## Unresolved questions/concerns
- Is changing the linker considered a breaking change? In (hopefully very rare) cases, it might break some existing code. It should mostly only affect the final linked artifact, so it should be easy to opt out.
- Similarly, is the single-threaded behavior of such tools encompassed in our stability guarantee: it can be observed via the `-j` job limit (though I believe we have/had some open issues on sometimes using more CPU resources than the job count limit implied). As mentioned above, LLD does not support the jobserver protocol.
- A concern [was raised](https://github.com/rust-lang/rust/issues/71515#issuecomment-2612370229 ) about increased memory usage of LLD. We should probably let users know about the possibly increased memory usage, and jobserver incompatibility: we did so when announcing this landing on nightly.
- LLD seems to produce [slightly larger](https://perf.rust-lang.org/compare.html?start=b3e117044c7f707293edc040edb93e7ec5f7040a&end=baed03c51a68376c1789cc373581eea0daf89967&stat=size%3Alinked_artifact&tab=compile ) binary artifacts. This can be partially clawed back using Identical Code Folding (`-Clink-args=-Wl,--icf=all`).
- Should we detect the outdated `.ctors/.dtors` sections to provide a better error message, even if that should be rare in practice?
---
### Next steps
After the FCP completes:
- we should land this PR at the beginning of a beta cycle, to maximize time for testing
- keep an eye on the beta crater run results for possible linker issues (or do a dedicated beta crater run with only this change)
- release a blog post announcing the change, and asking for testing feedback of the appropriate beta
- depending on feedback, or if a period of testing of 6 weeks is not long enough, we could keep this change on beta for another cycle
---
Development, testing, try builds were done in https://github.com/rust-lang/rust/pull/138645 .
r? `@petrochenkov`
`@rustbot` label +needs-fcp +T-compiler
2025-07-08 22:24:06 +00:00
bors
ab68b0fb26
Auto merge of #143645 - matthiaskrgr:rollup-d2a3leo, r=matthiaskrgr
...
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#143402 (Port several linking (linkage?) related attributes the new attribute system )
- rust-lang/rust#143555 (Don't mark `#[target_feature]` safe fns as unsafe in rustdoc JSON.)
- rust-lang/rust#143593 (Port #[rustc_dummy])
- rust-lang/rust#143600 (Update intro blurb in `wasm32-wasip1` docs)
- rust-lang/rust#143603 (Clarify the meaning of `AttributeOrder::KeepFirst` and `AttributeOrder::KeepLast`)
- rust-lang/rust#143620 (fix: Remove newline from multiple crate versions note)
- rust-lang/rust#143622 (Add target maintainer information for mips64-unknown-linux-muslabi64)
Failed merges:
- rust-lang/rust#143403 (Port several trait/coherence-related attributes the new attribute system)
r? `@ghost`
`@rustbot` modify labels: rollup
2025-07-08 17:31:40 +00:00
Matthias Krüger
f3226b47b8
Rollup merge of #143622 - Gelbpunkt:mips64-unknown-linux-muslabi64-target-maintainer, r=jieyouxu
...
Add target maintainer information for mips64-unknown-linux-muslabi64
The `mips64-unknown-linux-muslabi64` target is currently rather broken, but I'm working on getting it fixed so that it can at least be used again.
While I can't commit to maintaining the LLVM side of this target, I don't mind looking into any other MIPS or musl-related issues that arise with this target.
See e.g. rust-lang/rust#143409 for some rustc fixes I have in the pipeline and https://github.com/rust-lang/libc/pull/4509 , https://github.com/rust-lang/libc/pull/4527 , https://github.com/rust-lang/libc/pull/4528 , https://github.com/rust-lang/libc/pull/4529 , https://github.com/rust-lang/libc/pull/4530 for fixing the libc definitions for this target.
I'm adding myself as a maintainer mostly due to [this interaction](https://github.com/rust-lang/libc/pull/4530#issuecomment-3045912645 ).
LLVM support has been a concern for these targets in the past, but it shouldn't hurt to have a nominal maintainer for these even if they remain tier 3. From my experience, LLVM for MIPS is working well nowadays unless you decide to use LLD, which is horribly broken on MIPS.
2025-07-08 19:29:42 +02:00
Matthias Krüger
38bfba6124
Rollup merge of #143620 - Muscraft:remove-newline, r=compiler-errors
...
fix: Remove newline from multiple crate versions note
While working on getting `annotate-snippets` to match `rustc`, `annotate-snippets` was adding an extra new line after [this line](a2d45f73c7/tests/run-make/crate-loading/multiple-dep-versions.stderr (L9)a2d45f73c7/tests/run-make/crate-loading/multiple-dep-versions.rs2f8eeb2bba/compiler/rustc_errors/src/emitter.rs (L1542)
2025-07-08 19:29:41 +02:00
Matthias Krüger
a15162061b
Rollup merge of #143603 - Periodic1911:clarify_keepfistlast, r=compiler-errors
...
Clarify the meaning of `AttributeOrder::KeepFirst` and `AttributeOrder::KeepLast`
Clarify the meaning of `KeepLast` and `KeepFirst` for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971353197
Just a minor clarification, but me and ``@JonathanBrouwer`` have confused these two a few times so I think it's warranted.
r? ``@oli-obk``
cc ``@JonathanBrouwer``
2025-07-08 19:29:40 +02:00
Matthias Krüger
2c9247423e
Rollup merge of #143600 - alexcrichton:wasm32-wasip1-doc-reword, r=jieyouxu
...
Update intro blurb in `wasm32-wasip1` docs
I was reading over this documentation in light of the effort to enlist more maintainers for Tier 2 targets and figured it was time for a refresh of this documentation now that historical renames/etc have all become a thing of the past. No new major changes to this documentation, mostly just wanted to update it and reflect the modern status quo for this target.
2025-07-08 19:29:39 +02:00
Matthias Krüger
19a21289ba
Rollup merge of #143593 - mejrs:dummy, r=jdonszelmann
...
Port #[rustc_dummy]
r? ``@jdonszelmann``
2025-07-08 19:29:39 +02:00
Matthias Krüger
cbf7f80d5c
Rollup merge of #143555 - obi1kenobi:pg/target-feature-not-unsafe-rustdoc-json, r=aDotInTheVoid
...
Don't mark `#[target_feature]` safe fns as unsafe in rustdoc JSON.
Fixes https://github.com/rust-lang/rust/issues/142655 by explicitly checking whether functions are safe but using `#[target_feature]`, instead of relying on the `FnHeader::is_unsafe()` method which considers such functions unsafe.
I don't believe this merits a bump of the rustdoc JSON `FORMAT_VERSION` constant, since the format is unchanged and this is just a small bugfix.
r? aDotInTheVoid
2025-07-08 19:29:38 +02:00
Matthias Krüger
bc9b313cb5
Rollup merge of #143402 - GrigorenkoPV:attributes/link_attrs, r=jdonszelmann
...
Port several linking (linkage?) related attributes the new attribute system
This ports:
- `#[export_stable]`
- `#[ffi_const]`
- `#[ffi_pure]`
- `#[rustc_std_internal_symbol]`
Part of rust-lang/rust#131229
r? ``@oli-obk``
2025-07-08 19:29:37 +02:00
bors
f838cbc06d
Auto merge of #134628 - estebank:const-default, r=oli-obk
...
Make `Default` const and add some `const Default` impls
Full list of `impl const Default` types:
- ()
- bool
- char
- std::ascii::Char
- usize
- u8
- u16
- u32
- u64
- u128
- i8
- i16
- i32
- i64
- i128
- f16
- f32
- f64
- f128
- std::marker::PhantomData<T>
- Option<T>
- std::iter::Empty<T>
- std::ptr::Alignment
- &[T]
- &mut [T]
- &str
- &mut str
- String
- Vec<T>
2025-07-08 14:04:40 +00:00
bors
040e2f8b9f
Auto merge of #143540 - yotamofek:pr/library/simplify-num-fmt, r=tgross35
...
Simplify num formatting helpers
Noticed `ilog10` was being open-coded when looking at this diff: 85d6768f4c..76d9775912 (diff-6be9b44b52d946ccac652ddb7c98146a01b22ea0fc5737bc10db245a24796a45)😁
(should probably go through perf just to make sure it doesn't regress formatting)
2025-07-08 10:54:22 +00:00
Rémy Rakic
5059315e28
remove -znostart-stop-gc workaround
...
Now that `#[used(linker)]` is the default on ELF, we don't need to use the
`-znostart-stop-gc` link-arg workaround to match bfd's behavior when
using lld.
2025-07-08 10:24:11 +00:00
Rémy Rakic
889638a8b3
document new stable flags, with x64 linux implementation notes
2025-07-08 10:24:11 +00:00
Rémy Rakic
e32b1d7126
expand -Clink-self-contained tests
...
- update existing tests for stabilization
- ensure `-Clink-self-contained=-linker` is only stable on x64 linux
- test invalid `-Clink-self-contained` components
2025-07-08 10:24:10 +00:00
Rémy Rakic
856c662567
expand -Clinker-features tests
...
- ensure only `-Clinker-features=-lld` is stabilized, and only on x64
linux
- test `-Clinker-features` unstable values
2025-07-08 09:30:44 +00:00
Rémy Rakic
d6179022c1
update bootstrap mcp510 handling
...
beta and stage1 need to use different flags (-C vs -Z) to be able to use
the old and new `linker-features` and `link-self-contained` flags
2025-07-08 09:21:35 +00:00
Rémy Rakic
3f194a86ee
stabilize -Clink-self-contained=-linker on x64 linux
...
This stabilizes a subset of the `-Clink-self-contained` components on x64 linux:
the rust-lld opt-out.
The opt-in is not stabilized, as interactions with other stable flags require
more internal work, but are not needed for stabilizing using rust-lld by default.
Similarly, since we only switch to rust-lld on x64 linux, the opt-out is
only stabilized there. Other targets still require `-Zunstable-options`
to use it.
2025-07-08 09:21:35 +00:00
Rémy Rakic
2e6d82c9c9
stabilize -Clinker-features=-lld on x64 linux
...
This stabilizes a subset of the `-Clinker-features` components on x64 linux:
the lld opt-out.
The opt-in is not stabilized, as interactions with other stable flags require
more internal work, but are not needed for stabilizing using rust-lld by default.
Similarly, since we only switch to rust-lld on x64 linux, the opt-out is
only stabilized there. Other targets still require `-Zunstable-options`
to use it.
2025-07-08 09:04:21 +00:00
Rémy Rakic
aa52711543
add post-dist test for checking that we use LLD
...
And remove the previous beta/stable/nightly LLD tests.
2025-07-08 08:08:40 +00:00
Rémy Rakic
a4ea949356
use LLD by default on x64 regardless of channel
2025-07-08 08:08:40 +00:00
bors
45b80ac21a
Auto merge of #142869 - nnethercote:join_path-mini, r=camelid
...
Use `join_with_double_colon` in `write_shared.rs`.
For consistency. Also, it's faster because `join_with_double_colon` does a better job estimating the allocation size than `join` from `itertools`.
r? `@camelid`
2025-07-08 06:32:37 +00:00
bors
2783fc43fd
Auto merge of #143621 - matthiaskrgr:rollup-p1ce8l7, r=matthiaskrgr
...
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#142098 (Implement `int_format_into` feature)
- rust-lang/rust#143567 (Point to correct argument in Func Call when Self type fails trait bound)
- rust-lang/rust#143570 (consider nested cases for duplicate RPITIT)
- rust-lang/rust#143571 (remove `has_nested` from builtin candidates)
- rust-lang/rust#143586 (Fix wrong cache event query key)
- rust-lang/rust#143589 (const-block-as-pattern: do not refer to no-longer-existing nightly feature)
- rust-lang/rust#143608 (Fix in std::String docs)
r? `@ghost`
`@rustbot` modify labels: rollup
2025-07-08 03:30:58 +00:00
Predrag Gruevski
717041232a
Don't mark #[target_feature] safe fns as unsafe in rustdoc JSON.
2025-07-08 02:02:56 +00:00
Jens Reidel
a58a423f9a
Add target maintainer information for mips64-unknown-linux-muslabi64
...
The mips64-unknown-linux-muslabi64 target is currently rather broken,
but I'm working on getting it fixed so that it can at least be used
again.
While I can't commit to maintaining the LLVM side of this target, I
don't mind looking into any other MIPS or musl-related issues that arise
with this target.
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
2025-07-08 03:17:04 +02:00
Matthias Krüger
fd05071727
Rollup merge of #143608 - codexarafat:fix-string-doc, r=Noratrieb
...
Fix in std::String docs
This PR removes the word “else” from the sentence ('something else similar') in the String documentation to improve clarity.
Fixes rust-lang/rust#143579 .
2025-07-08 03:09:59 +02:00
Matthias Krüger
65dded8387
Rollup merge of #143589 - RalfJung:const-pat, r=compiler-errors
...
const-block-as-pattern: do not refer to no-longer-existing nightly feature
Surely everyone who used this nightly feature has fixed their code by now. So let's not confused people on stable that try to use a const block as a pattern by referring to some dead nightly feature.
2025-07-08 03:09:58 +02:00
Matthias Krüger
1a45ab116d
Rollup merge of #143586 - Kobzol:self-profile-fix, r=oli-obk
...
Fix wrong cache event query key
I messed this up in https://github.com/rust-lang/rust/pull/142978 . It is only an issue if someone enables the event manually, which almost no-one does, so it could take a while before we found it :D Luckily I noticed it while re-reading the PR.
r? `@oli-obk`
2025-07-08 03:09:58 +02:00
Matthias Krüger
b29f039ae3
Rollup merge of #143571 - lcnr:has_nested-bb, r=compiler-errors
...
remove `has_nested` from builtin candidates
it's no longer necessary
r? types
2025-07-08 03:09:57 +02:00
Matthias Krüger
a4e05e1f74
Rollup merge of #143570 - bvanjoi:issue-143560, r=compiler-errors
...
consider nested cases for duplicate RPITIT
Fixes rust-lang/rust#143560
r? `@compiler-errors`
cc `@Zoxc`
2025-07-08 03:09:57 +02:00
Matthias Krüger
40e1ccf458
Rollup merge of #143567 - xizheyin:143336, r=compiler-errors
...
Point to correct argument in Func Call when Self type fails trait bound
Fixes rust-lang/rust#143336
When a trait bound fails due to the `Self` type parameter, `adjust_fulfillment_errors` now correctly points to the corresponding function argument instead of incorrectly pointing to other arguments. This is because `Call` may also need to handle the `self` parameter, and not just `MethodCall` needs to be handled, as rust-lang/rust#143336 .
r? compiler
2025-07-08 03:09:56 +02:00
Matthias Krüger
d41f046de5
Rollup merge of #142098 - GuillaumeGomez:int_format_into, r=Amanieu
...
Implement `int_format_into` feature
I took over rust-lang/rust#138338 with `@madhav-madhusoodanan's` approval.
Since https://github.com/rust-lang/rust/pull/136264 , a lot of changes happened so I made use of them to reduce the number of changes.
ACP approval: https://github.com/rust-lang/libs-team/issues/546#issuecomment-2707244569
## Associated Issue
- https://github.com/rust-lang/rust/issues/138215
r? `@hanna-kruppe`
2025-07-08 03:09:56 +02:00
Scott Schafer
62951c2e07
fix: Remove newline from multiple crate versions note
2025-07-07 18:54:23 -06:00
bors
688ea65df6
Auto merge of #143433 - oli-obk:ty_span_qry, r=compiler-errors
...
Add `ty_span` query
r? `@compiler-errors`
fixes diagnostic regressions from https://github.com/rust-lang/rust/pull/142030
Also uses the new query in `check_const_item`
2025-07-08 00:11:13 +00:00
Esteban Küber
8f8099fb42
Account for const stability in clippy when checking constness
2025-07-07 23:07:32 +00:00
Esteban Küber
c3301503b9
Make Default const and add some const Default impls
...
Full list of `impl const Default` types:
- ()
- bool
- char
- Cell
- std::ascii::Char
- usize
- u8
- u16
- u32
- u64
- u128
- i8
- i16
- i32
- i64
- i128
- f16
- f32
- f64
- f128
- std::marker::PhantomData<T>
- Option<T>
- std::iter::Empty<T>
- std::ptr::Alignment
- &[T]
- &mut [T]
- &str
- &mut str
- String
- Vec<T>
2025-07-07 22:09:37 +00:00
bors
a2d45f73c7
Auto merge of #143601 - matthiaskrgr:rollup-9iw2sqk, r=matthiaskrgr
...
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#132469 (Do not suggest borrow that is already there in fully-qualified call)
- rust-lang/rust#143340 (awhile -> a while where appropriate)
- rust-lang/rust#143438 (Fix the link in `rustdoc.md`)
- rust-lang/rust#143539 (Regression tests for repr ICEs)
- rust-lang/rust#143566 (Fix `x86_64-unknown-netbsd` platform support page)
- rust-lang/rust#143572 (Remove unused allow attrs)
- rust-lang/rust#143583 (`loop_match`: fix 'no terminator on block')
- rust-lang/rust#143584 (make `Machine::load_mir` infallible)
- rust-lang/rust#143591 (Fix missing words in future tracking issue)
r? `@ghost`
`@rustbot` modify labels: rollup
2025-07-07 20:30:53 +00:00
Md. Yeasin Arafat
2bff99c275
Fix in String docs: remove 'else' from 'something else similar'
2025-07-08 01:05:16 +06:00
Anne Stijns
6254afa5f2
Clarify the meaning of AttributeOrder::KeepFirst and AttributeOrder::KeepLast
2025-07-07 20:29:06 +02:00
Matthias Krüger
ff6b881c8d
Rollup merge of #143591 - ehuss:future-typos, r=jieyouxu
...
Fix missing words in future tracking issue
Fixes some sloppy editing on my part.
2025-07-07 19:55:37 +02:00
Matthias Krüger
42b105eb21
Rollup merge of #143584 - fee1-dead-contrib:push-skswvrwsrmll, r=RalfJung
...
make `Machine::load_mir` infallible
it doesn't need to return an `InterpResult`.
2025-07-07 19:55:36 +02:00
Matthias Krüger
f5df1f562c
Rollup merge of #143583 - folkertdev:loop-match-no-terminator-on-block, r=bjorn3
...
`loop_match`: fix 'no terminator on block'
tracking issue: https://github.com/rust-lang/rust/issues/132306
fixes https://github.com/rust-lang/rust/issues/143435
The argument `block` was not properly closed on an error path.
r? `@bjorn3`
2025-07-07 19:55:35 +02:00
Matthias Krüger
7ed6bd98a2
Rollup merge of #143572 - yotamofek:pr/unused-allow-attrs, r=fee1-dead
...
Remove unused allow attrs
These `#[allow]`s seem to be unused (at least according to `x check`, didn't run `x test` locally). Let's clean them up! 🧹
2025-07-07 19:55:35 +02:00
Matthias Krüger
b6777b1939
Rollup merge of #143566 - jieyouxu:fix-x86_64-unknown-netbsd, r=fee1-dead
...
Fix `x86_64-unknown-netbsd` platform support page
`x86_64-unknown-netbsd` is Tier 2 with host tools, not Tier 3.
cc `@he32.`
r? compiler
2025-07-07 19:55:34 +02:00
Matthias Krüger
6c8482ee2c
Rollup merge of #143539 - JonathanBrouwer:ice-regression-tests, r=oli-obk
...
Regression tests for repr ICEs
Closes https://github.com/rust-lang/rust/issues/143522
Closes https://github.com/rust-lang/rust/issues/143479
Both issues were already (accidentally) fixed in this PR, but having the tests is nice https://github.com/rust-lang/rust/pull/143252
r? `@jdonszelmann`
2025-07-07 19:55:33 +02:00
Matthias Krüger
1b922d3901
Rollup merge of #143438 - makai410:rustdoc-fix, r=ehuss
...
Fix the link in `rustdoc.md`
2025-07-07 19:55:33 +02:00
Matthias Krüger
2554c424ef
Rollup merge of #143340 - nabijaczleweli:awhile, r=mati865
...
awhile -> a while where appropriate
2025-07-07 19:55:32 +02:00
Matthias Krüger
00a4418158
Rollup merge of #132469 - estebank:issue-132041, r=Nadrieril
...
Do not suggest borrow that is already there in fully-qualified call
When encountering `&str::from("value")` do not suggest `&&str::from("value")`.
Fix #132041 .
2025-07-07 19:55:31 +02:00
