Matthias Krüger
dbd2f30395
Rollup merge of #143708 - epage:pretty, r=compiler-errors
...
fix: Include frontmatter in -Zunpretty output
In the implementation (rust-lang/rust#140035 ), this was left as an open question for
the tracking issue (rust-lang/rust#136889 ). My assumption is that this should be
carried over.
The test was carried over from rust-lang/rust#137193 which was superseded by rust-lang/rust#140035 .
Thankfully, either way, `-Zunpretty` is unstable and we can always
change it even if we stabilize frontmatter.
2025-07-11 07:35:21 +02:00
Matthias Krüger
b5b35f1aa4
Rollup merge of #143683 - jieyouxu:rms-cleanup, r=Kobzol
...
Assorted `run-make-support` maintenance
This PR should contain no functional changes.
- Commit 1: Removes the support library's CHANGELOG. In the very beginning, I thought maybe we would try to version this library. But this is a purely internal test support library, and it's just extra busywork trying to maintain changelog/versions. It's also hopelessly outdated.
- Commit 2: Resets version number to `0.0.0`. Ditto on busywork.
- Commit 3: Bump `run-make-support` to Edition 2024. The support library was already "compliant" with Edition 2024.
- Commit 4: Slightly organizes the support library dependencies.
- Commit 5: Previously, I tried hopelessly to maintain some manual formatting, but that was annoying because it required skipping rustfmt (so export ordering etc. could not be extra formatted). Give up, and do some rearrangements / module prefix tricks to get the `lib.rs` looking at least *reasonable*. IMO this is not a strict improvement, but I rather regain the ability to auto-format it with rustfmt.
- Commit {6,7}: Noticed in rust-lang/rust#143669 that we apparently had *both* {`is_msvc`, `is_windows_msvc`}. This PR removes `is_msvc` in favor of `is_windows_msvc` to make it unambiguous (and only retain one way of gating) as there are some UEFI targets which are MSVC but not Windows.
Best reviewed commit-by-commit.
r? `@Kobzol`
2025-07-10 15:19:35 +02:00
Matthias Krüger
a0c7887199
Rollup merge of #136906 - chenyukang:yukang-fix-136741-closure-body, r=oli-obk
...
Add checking for unnecessary delims in closure body
Fixes #136741
2025-07-10 15:19:29 +02:00
Trevor Gross
58ec9db538
Rollup merge of #143398 - lolbinarycat:tidy-extra-checks-auto, r=Kobzol
...
tidy: add support for `--extra-checks=auto:` feature
in preparation for rust-lang/rust#142924
also heavily refactored the parsing of the `--extra-checks` argument to warn about improper usage.
cc ```@GuillaumeGomez```
r? ```@Kobzol```
2025-07-10 03:23:57 -04:00
Jieyou Xu
87a41210d4
Only provide is_windows_msvc to gate on windows-msvc
...
And not both `is_windows_msvc` and `is_msvc`.
2025-07-10 13:54:43 +08:00
yukang
4dc954f882
remove unnecessary parens in rust-analyzer
2025-07-10 13:50:02 +08:00
yukang
93db9e7ee0
Remove uncessary parens in closure body with unused lint
2025-07-10 09:25:56 +08:00
Ed Page
45a1e492b1
feat(lexer): Allow including frontmatter with 'tokenize'
2025-07-09 16:42:27 -05:00
Jieyou Xu
200f132367
Massage lib.rs so it can be rustfmt'd
...
Even if the formatting isn't strictly "better", it at least allows
rustfmtting it automatically.
2025-07-09 20:30:49 +08:00
Jieyou Xu
fae15466aa
Sort and document run-make-support dependencies
2025-07-09 20:10:32 +08:00
Jieyou Xu
e70493d06c
Bump run-make-support to Edition 2024
2025-07-09 20:07:09 +08:00
Jieyou Xu
ed520af279
Don't attempt to version run-make-support
...
Purely internal test support library.
2025-07-09 20:05:13 +08:00
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
6b3ae3f6e4
Auto merge of #143472 - dianne:deref-pat-column-check, r=Nadrieril
...
`rustc_pattern_analysis`: always check that deref patterns don't match on the same place as normal constructors
In rust-lang/rust#140106 , deref pattern validation was tied to the `deref_patterns` feature to temporarily avoid affecting perf. However:
- As of rust-lang/rust#143414 , box patterns are represented as deref patterns in `rustc_pattern_analysis`. Since they can be used by enabling `box_patterns` instead of `deref_patterns`, it was possible for them to skip validation, resulting in an ICE. This fixes that and adds a regression test.
- External tooling (e.g. rust-analyzer) will also need to validate matches containing deref patterns, which was not possible. This fixes that by making `compute_match_usefulness` validate deref patterns by default.
In order to avoid doing an extra pass for anything with patterns, the second commit makes `RustcPatCtxt` keep track of whether it encounters a deref pattern, so that it only does the check if so. This is purely for performance. If the perf impact of the first commit is negligible and the complexity cost introduced by the second commit is significant, it may be worth dropping the latter.
r? `@Nadrieril`
2025-07-09 09:45:36 +00:00
Trevor Gross
00aa4e1627
Rollup merge of #143520 - Stypox:enter_trace_span-closure, r=RalfJung
...
Fix perf regression caused by tracing
See rust-lang/rust#143334 , this is another alternative that may be worth benchmarking as suggested in https://github.com/rust-lang/rust/pull/143334#issuecomment-3038953172 .
r? ``@RalfJung``
2025-07-08 22:50:29 -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
binarycat
9aafc98244
tidy: assume all files are modified in CI
2025-07-08 16:16:48 -05:00
binarycat
6b349a41da
tidy: warn when --extra-checks is passed an invalid lang:kind combo
...
Co-authored-by: Jakub Beránek <berykubik@gmail.com>
2025-07-08 16:16:48 -05:00
binarycat
64456e07b8
tidy: add auto: prefix to --extra-checks syntax
...
currently this just uses a very simple
extension-based heirustic.
2025-07-08 16:16:48 -05:00
binarycat
4a6f6977f9
tidy: update files_modified to take CiInfo
2025-07-08 16:16:45 -05:00
binarycat
9eb180541a
tidy: factor out change detection logic and make it more robust
...
now does proper parsing of git's output and falls back to
assuming all files are modified if `git` doesn't work.
accepts a closure so extensions can be checked.
2025-07-08 16:16:11 -05:00
binarycat
66bc234087
tidy: refactor --extra-checks parsing
2025-07-08 12:39:38 -05: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
Stypox
e5f7d4d783
Implement enter_trace_span() in MiriMachine
2025-07-08 15:37:01 +02: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
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
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
bors
2f8eeb2bba
Auto merge of #143182 - xdoardo:more-addrspace, r=workingjubilee
...
Allow custom default address spaces and parse `p-` specifications in the datalayout string
Some targets, such as CHERI, use as default an address space different from the "normal" default address space `0` (in the case of CHERI, [200 is used](https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-877.pdf )). Currently, `rustc` does not allow to specify custom address spaces and does not take into consideration [`p-` specifications in the datalayout string](https://llvm.org/docs/LangRef.html#langref-datalayout ).
This patch tries to mitigate these problems by allowing targets to define a custom default address space (while keeping the default value to address space `0`) and adding the code to parse the `p-` specifications in `rustc_abi`. The main changes are that `TargetDataLayout` now uses functions to refer to pointer-related informations, instead of having specific fields for the size and alignment of pointers in the default address space; furthermore, the two `pointer_size` and `pointer_align` fields in `TargetDataLayout` are replaced with an `FxHashMap` that holds info for all the possible address spaces, as parsed by the `p-` specifications.
The potential performance drawbacks of not having ad-hoc fields for the default address space will be tested in this PR's CI run.
r? workingjubilee
2025-07-07 17:28:14 +00:00
许杰友 Jieyou Xu (Joe)
eed55947ac
Rollup merge of #143528 - RalfJung:stack-pop-cleanup, r=oli-obk
...
interpret: rename StackPopCleanup
The name `StackPopCleanup` stopped making sense a long time ago IMO -- in the common case, it has nothing to do with "cleanup", and everything with where the program should jump next. If we didn't have unwinding this would be just the return block, but given that we do have unwinding I figured maybe "continuation" would be a good name. This comes up in [continuation-passing style](https://en.wikipedia.org/wiki/Continuation-passing_style ) and refers to where the program will *continue* when a function is done. So from a PL perspective it is the most fitting term I think -- but it may be too jargony.
r? `@oli-obk` what do you think?
2025-07-07 19:45:41 +08:00
bors
8df4a58ac4
Auto merge of #143565 - lnicola:sync-from-ra, r=lnicola
...
Subtree update of `rust-analyzer`
r? `@ghost`
2025-07-07 08:14:30 +00:00
Edoardo Marangoni
93f1201c06
compiler: Parse p- specs in datalayout string, allow definition of custom default data address space
2025-07-07 09:04:53 +02:00
bors
0d11be5aab
Auto merge of #143556 - jhpratt:rollup-nid39y2, r=jhpratt
...
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#143206 (Align attr fixes)
- rust-lang/rust#143236 (Stabilize `mixed_integer_ops_unsigned_sub`)
- rust-lang/rust#143344 (Port `#[path]` to the new attribute parsing infrastructure )
- rust-lang/rust#143359 (Link to 2024 edition page for `!` fallback changes)
- rust-lang/rust#143456 (mbe: Change `unused_macro_rules` to a `DenseBitSet`)
- rust-lang/rust#143529 (Renamed retain_mut to retain on LinkedList as mentioned in the ACP)
- rust-lang/rust#143535 (Remove duplicate word)
- rust-lang/rust#143544 (compiler: rename BareFn to FnPtr)
- rust-lang/rust#143552 (lib: more eagerly return `self.len()` from `ceil_char_boundary`)
r? `@ghost`
`@rustbot` modify labels: rollup
2025-07-07 02:03:03 +00:00
Jacob Pratt
7eea141b87
Rollup merge of #143544 - workingjubilee:rename-bare-fn, r=fmease
...
compiler: rename BareFn to FnPtr
At some point "BareFn" was the chosen name for a "bare" function, without the niceties of `~fn`, `&fn`, or a few other ways of writing a function type. However, at some point the syntax for a "bare function" and any other function diverged even more. We started calling them what they are: function pointers, denoted by their own syntax.
However, we never changed the *internal* name for these, as this divergence was very gradual. Personally, I have repeatedly searched for "FnPtr" and gotten confused until I find the name is BareFn, only to forget this until the next time, since I don't routinely interact with the higher-level AST and HIR. But even tools that interact with these internal types only touch on them in a few places, making a migration easy enough. Let's use a more intuitive and obvious name, as this 12+ year old name has little to do with current Rust.
2025-07-07 03:26:09 +02:00
bors
ca98d4d4b3
Auto merge of #141829 - dvdsk:sleep_until_linux, r=cuviper,RalfJung
...
Specialize sleep_until implementation for unix (except mac)
related tracking issue: https://github.com/rust-lang/rust/issues/113752
Supersedes https://github.com/rust-lang/rust/pull/118480 for the reasons see: https://github.com/rust-lang/rust/issues/113752#issuecomment-2902594469
Replaces the generic catch all implementation with target_os specific ones for: linux/netbsd/freebsd/android/solaris/illumos etc. Other platforms like wasi, macos/ios/tvos/watchos and windows will follow in later separate PR's (once this is merged).
2025-07-06 23:00:51 +00:00
Jubilee Young
3c9b98699d
rustfmt: migrate BareFn -> FnPtr
2025-07-06 15:03:14 -07:00
Jubilee Young
e47f5657e1
clippy: migrate BareFn -> FnPtr
2025-07-06 15:03:14 -07:00
bors
de031bbcb1
Auto merge of #143526 - matthiaskrgr:rollup-pm69g5v, r=matthiaskrgr
...
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#143252 (Rewrite empty attribute lint for new attribute parser)
- rust-lang/rust#143492 (Use `object` crate from crates.io to fix windows build error)
- rust-lang/rust#143514 (Organize macro tests a bit more)
- rust-lang/rust#143518 (rustc_builtin_macros: Make sure registered attributes stay sorted)
r? `@ghost`
`@rustbot` modify labels: rollup
2025-07-06 16:56:16 +00:00
dvdsk
61cf174dce
sleep_until: add clock_nanosleep support to Miri
...
The clock_nanosleep support is there to allow code using `sleep_until`
to run under Miri. Therefore the implementation is minimal.
- Only the clocks REALTIME and MONOTONIC are supported. The first is supported simply
because it was trivial to add not because it was needed for sleep_until.
- The only supported flag combinations are no flags or TIMER_ABSTIME only.
If an unsupported flag combination or clock is passed in this throws
unsupported.
2025-07-06 17:49:35 +02:00
Ralf Jung
7775166528
interpret: rename StackPopCleanup
2025-07-06 16:07:35 +02:00
Matthias Krüger
017fe2fb8f
Rollup merge of #143252 - JonathanBrouwer:rewrite_empty_attribute, r=jdonszelmann
...
Rewrite empty attribute lint for new attribute parser
cc `@jdonszelmann`
2025-07-06 15:56:12 +02:00
bors
3c95364c4a
Auto merge of #143515 - rust-lang:cargo_update, r=clubby789
...
Weekly `cargo update`
Automation to keep dependencies in `Cargo.lock` current.
r? dep-bumps
The following is the output from `cargo update`:
```txt
compiler & tools dependencies:
Locking 6 packages to latest compatible versions
Adding io-uring v0.7.8
Updating jsonpath-rust v1.0.2 -> v1.0.3
Updating libffi v4.1.0 -> v4.1.1
Updating libffi-sys v3.3.1 -> v3.3.2
Updating tokio v1.45.1 -> v1.46.1
Updating wasm-component-ld v0.5.14 -> v0.5.15
note: pass `--verbose` to see 41 unchanged dependencies behind latest
library dependencies:
Locking 0 packages to latest compatible versions
note: pass `--verbose` to see 4 unchanged dependencies behind latest
rustbook dependencies:
Locking 1 package to latest compatible version
Updating cc v1.2.27 -> v1.2.29
```
2025-07-06 13:53:52 +00:00
Lukas Wirth
1cf9a7bd7b
Merge pull request #20184 from Veykril/push-ywpynxnltpok
...
chore: Remove dead field from `InferenceContext`
2025-07-06 09:08:36 +00:00
Lukas Wirth
836e0cbccf
chore: Remove dead field from InferenceContext
2025-07-06 10:57:06 +02:00
Matthias Krüger
097efc07cc
Rollup merge of #143504 - RalfJung:compiletest-err, r=jieyouxu
...
compiletest: print slightly more information on fs::write failure
See [#t-infra > compiletest: panic in dump_output_file: No such file or dire @ 💬 ](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/compiletest.3A.20panic.20in.20dump_output_file.3A.20No.20such.20file.20or.20dire/near/527294714 )
2025-07-06 10:03:24 +02:00
Matthias Krüger
e25654fb94
Rollup merge of #143493 - lolbinarycat:tidy-spellcheck-bless, r=Kobzol
...
tidy: use --bless for tidy spellcheck instead of spellcheck:fix
previous behavior was inconsistent with existing extra checks.
unsure if this needs a change tracker entry or a warning for people who try to use the old behavior.
unsure if we should call this `spellcheck:lint` for consistency.
making this consistent is a prerequisite for https://github.com/rust-lang/rust/pull/143398
cc `@nnethercote`
r? `@Kobzol`
2025-07-06 10:03:24 +02:00
Lukas Wirth
eca5905364
Merge pull request #20132 from A4-Tacks/asmut-borrow-minicore
...
Add AsMut, Borrow and BorrowMut to minicore and famous_defs
2025-07-06 08:01:54 +00:00
Lukas Wirth
37f2263438
Merge pull request #20126 from Wilfred/no_unwrap_in_discover_projects
...
fix: Avoid .unwrap() when running the discover command
2025-07-06 08:01:10 +00:00
Jonathan Brouwer
3fa0ec91d8
Rewrite empty attribute lint
...
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-07-06 09:51:35 +02:00
