Rustc pull update #2551
Merged
Rustc pull update #2551
Conversation
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
![workflows-rustc-dev-guide[bot]](https://avatars.githubusercontent.com/u/5430905?s=60&v=4){kind=small}
This removes the #[no_sanitize] attribute, which was behind an unstable feature named no_sanitize. Instead, we introduce the sanitize attribute which is more powerful and allows to be extended in the future (instead of just focusing on turning sanitizers off). This also makes sanitize(kernel_address = ..) attribute work with -Zsanitize=address To do it the same as how clang disables address sanitizer, we now disable ASAN on sanitize(kernel_address = "off") and KASAN on sanitize(address = "off"). The same was added to clang in https://reviews.llvm.org/D44981.
library: Migrate from `cfg_if` to `cfg_select`
Migrate the standard library from using the external `cfg_if` crate to using the now-built-in `cfg_select` macro.
This does not yet eliminate the dependency from `library/std/Cargo.toml`, because while the standard library itself no longer uses `cfg_if`, it also incorporates the `backtrace` crate, which does.
Migration assisted by the following vim command (after selecting the full `cfg_if!` invocation):
```
'<,'>s/\(cfg_if::\)\?cfg_if/cfg_select/ | '<,'>s/^\( *\)} else {/\1}\r\1_ => {/c | '<,'>s/^\( *\)} else if #\[cfg(\(.*\))\] /\1}\r\1\2 => /e | '<,'>s/if #\[cfg(\(.*\))\] {/\1 => {/e
```
This is imperfect, but substantially accelerated the process. This prompts for confirmation on the `} else {` since that can also appear inside one of the arms. This also requires manual intervention to handle any multi-line conditions.
`impl PartialEq<{str,String}> for {Path,PathBuf}`
This is a revival of #105877
Comparison of paths and strings is expected to be possible and needed e.g. in tests. This change adds the impls os `PartialEq` between strings and paths, both owned and unsized, in both directions.
ACP: rust-lang/libs-team#151
Stabilize `ip_from` Tracking issue: rust-lang/rust#131360 Stabilizes and const-stabilizes the following APIs: ```rust // core::net impl Ipv4Addr { pub const fn from_octets(octets: [u8; 4]) -> Ipv4Addr; } impl Ipv6Addr { pub const fn from_octets(octets: [u8; 16]) -> Ipv6Addr; pub const fn from_segments(segments: [u16; 8]) -> Ipv6Addr; } ``` Closes rust-lang/rust#131360 ```@rustbot``` label +needs-fcp
Remove the `#[no_sanitize]` attribute in favor of `#[sanitize(xyz = "on|off")]` This came up during the sanitizer stabilization (rust-lang/rust#123617). Instead of a `#[no_sanitize(xyz)]` attribute, we would like to have a `#[sanitize(xyz = "on|off")]` attribute, which is more powerful and allows to be extended in the future (instead of just focusing on turning sanitizers off). The implementation is done according to what was [discussed on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/343119-project-exploit-mitigations/topic/Stabilize.20the.20.60no_sanitize.60.20attribute/with/495377292)). The new attribute also works on modules, traits and impl items and thus enables usage as the following: ```rust #[sanitize(address = "off")] mod foo { fn unsanitized(..) {} #[sanitize(address = "on")] fn sanitized(..) {} } trait MyTrait { #[sanitize(address = "off")] fn unsanitized_default(..) {} } #[sanitize(thread = "off")] impl MyTrait for () { ... } ``` r? ```@rcvalle```
…ibraheemdev Trivial improve doc for transpose When I saw old doc, I felt a little confused. Seems it would be clearer this way.
Do not copy .rmeta files into the sysroot of the build compiler during check of rustc/std Before, when bootstrap did a check build of rustc stage N (with a build compiler that was stage N-1), it automatically copied the resulting `.rmeta` artifacts into the sysroot of the stage N-1 build compiler, so that stage N `rustc_private` tools such as `miri` could be compiled using the stage N-1 build compiler. This has a number of issues: - It was done unconditionally, even if no `rustc_private` tools were actually built. - If we did a check and a build of the same stage compiler in the same bootstrap invocation, the generated rmeta and rlib files could clash. This is also why you can see that `check::Std` actually doesn't copy the artifacts anymore (which forced us to build std instead of just checking it in a bunch of `Check` steps). - It was polluting the sysroot of the build compiler. This is especially annoying for the stage 0 compiler, because we are forced to create an artificial sysroot for it, so that we can copy new stuff into it. - It was very implicit in bootstrap. Based on suggestions by ```@cuviper``` and ```@bjorn3,``` I tried to change how this behaves. Instead of copying the rmeta artifacts into the sysroot of the build compiler (from where they would be loaded implicitly), they are now stored in a separate transient bootstrap build directory, and they are then explicitly passed *only* when checking `rustc_private` tools using the `-L` flag. The flags are passed out-of-band through our rustc wrapper, to avoid invalidating the build cache. This is the first commit. The second commit does the same for std. For a few months, we used to build std instead of just checking it when doing a cross-compile check of something that required std, this now fixes it. There is still the previous ordering requirement though, that `check::Std` has to be executed as the last check step, or rather nothing that requires checked std should be executed *after* it, because it will run into rmeta/rlib duplications (https://github.com/rust-lang/rust/blob/4fa90ef7996f891f7f1e126411e5d75afe64accf/src/bootstrap/src/core/builder/mod.rs#L1066). I tried to fix in this PR, but it quickly runs into the fact that building things currently copies *rlib* artifacts into the build compiler sysroot. I want to fix that as one of the next steps. After we get rid of all the copies (or rather, we only do the copies for dist/stage2+ and do not copy anything into the stage0 compiler's sysroot), we could hopefully finally get rid of `stage0-sysroot`. Based on my local tests, this seems to be working fine. If it works on CI, and we don't run into other issues after merging it, I'd like to do the same also for rlib artifacts generated during `x build`. r? ```@jieyouxu```
…at,GuillaumeGomez rustdoc-search: search backend with partitioned suffix tree Before: - https://notriddle.com/windows-docs-rs/doc-old/windows/ - https://doc.rust-lang.org/1.89.0/std/index.html - https://doc.rust-lang.org/1.89.0/nightly-rustc/rustc_hir/index.html After: - https://notriddle.com/windows-docs-rs/doc/windows/ - https://notriddle.com/rustdoc-html-demo-12/stringdex/doc/std/index.html - https://notriddle.com/rustdoc-html-demo-12/stringdex/compiler-doc/rustc_hir/index.html ## Summary Rewrites the rustdoc search engine to use an indexed data structure, factored out as a crate called [stringdex](https://crates.io/crates/stringdex), that allows it to perform modified-levenshtein distance calculations, substring matches, and prefix matches in a reasonably efficient, and, more importantly, *incremental* algorithm. ## Motivation Fixes rust-lang/rust#131156 While the windows-rs crate is definitely the worst offender, I've noticed performance problems with the compiler crates as well. It makes no sense for rustdoc-search to have poor performance: it's basically a spell checker, and those have been usable since the 90's. Stringdex is particularly designed to quickly return exact matches, to always report those matches first, and to never, ever [place new matches on top of old ones](https://web.dev/articles/cls). It also tries to yield to the event loop occasionally as it runs. This way, you can click the exactly-matched result before the rest of the search finishes running. ## Explanation A longer description of how name search works can be found in stringdex's [HACKING.md](https://gitlab.com/notriddle/stringdex/-/blob/main/HACKING.md) file. Type search is done by performing a name search on each element, then performing bitmap operations to narrow down a list of potential matches, then performing type unification on each match. ## Drawbacks It's rather complex, and takes up more disk space than the current flat list of strings. ## Rationale and alternatives Instead of a suffix tree, I could've used a different [approximate matching data structure](https://en.wikipedia.org/wiki/Approximate_string_matching). I didn't do that because I wanted to keep the current behavior (for example, a straightforward trigram index won't match [oepn](https://doc.rust-lang.org/nightly/std/?search=oepn) like the current system does). ## Prior art [Sherlodoc](https://github.com/art-w/sherlodoc) is based on a similar concept, but they: - use edit distance over a suffix tree for type-based search, instead of the binary matching that's implemented here - use substring matching for name-based search, [but not fuzzy name matching](art-w/sherlodoc#21) - actually implement body text search, which is a potential-future feature, but not implemented in this PR ## Future possibilities ### Low-level optimization in stringdex There are half a dozen low-level optimizations that I still need to explore. I haven't done them yet, because I've been working on bug fixes and rebasing on rustdoc's side, and a more solid and diverse test suite for stringdex itself. - Stringdex decides whether to bundle two nodes into the same file based on size. To figure out a node's size, I have to run compression on it. This is probably slower than it needs to be. - Stack compression is limited to the same 256-slot sliding windows as backref compression, and it doesn't have to be. (stack and backref compression are used to optimize the representation of the edge pointer from a parent node to its child; backref uses one byte, while stack is entirely implicit) - The JS-side decoder is pretty naive. It performs unnecessary hash table lookups when decoding compressed nodes, and retains a list of hashes that it doesn't need. It needs to calculate the hashes in order to construct the merkle tree correctly, but it doesn't need to keep them. - Data compression happens at the end, while emitting the node. This means it's not being counted when deciding on how to bundle, which is pretty dumb. ### Improved recall in type-driven search Right now, type-driven search performs very strict matching. It's very precise, but misses a lot of things people would want. What I'm not sure about is whether to focus more on edit-distance-based approaches, or to focus on type-theoretical approaches. Both gives avenues to improve, but edit distance is going to be faster while type checking is going to be more precise. For example, a type theoretical improvement would fix [`Iterator<T>, (T -> U) -> Iterator<U>`](https://doc.rust-lang.org/nightly/std/?search=Iterator%3CT%3E%2C%20(T%20-%3E%20U)%20-%3E%20Iterator%3CU%3E) to give [`Iterator::map`](https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.map), because it would recognize that the Map struct implements the Iterator trait. I don't know of any clean way to get this result to work without implementing significant type checking logic in search.js, and an edit-distance-based "dirty" approach would likely give a bunch of other results on top of this one. ## Full-text search Once you've got this fuzzy dictionary matching to work, the logical next step is to implement some kind of information retrieval-based approach to phrase matching. Like applying edit distance to types, phrase search gets you significantly better recall, but with a few major drawbacks: - You have to pick between index bloat and the use of stopwords. Stopwords are bad because they might actually be important (try searching "if let" in mdBook if you're feeling brave), but without them, you spend a lot of space on text that doesn't matter. - Example code also tends to have a lot of irrelevant stuff in it. Like stop words, we'd have to pick potentially-confusing or bloat. Neither of these problems are deal-breakers, but they're worth keeping in mind.
Fix RISC-V Test Failures in ./x test for Multiple Codegen Cases This PR resolves several test failures encountered when running `./x test` on the RISC-V architecture. These failures were caused by platform-specific behavior, ABI differences, or codegen inconsistencies unique to RISC-V. The following test cases have been fixed to ensure compatibility with RISC-V: * `codegen-llvm/enum/enum-match.rs` * `codegen-llvm/enum/enum-transparent-extract.rs` * `codegen-llvm/repeat-operand-zero-len.rs` * `codegen-llvm/enum/enum-aggregate.rs` * `codegen-llvm/uninhabited-transparent-return-abi.rs` In addition, this PR adjusts `tests/codegen-llvm/transmute-scalar.rs` to explicitly specify the target architecture: ```rust //@ compile-flags: --target=x86_64-unknown-linux-gnu //@ needs-llvm-components: x86 ``` As suggested by ```@nikic,``` this test is not target-specific and already uses `minicore`, implying it is meant to run against a stable triple regardless of the host architecture. Explicitly setting the target ensures consistent codegen behavior, particularly when testing on non-x86 platforms such as riscv64. All changes have been tested locally on a RISC-V target and now pass as expected. ### Notes: * These fixes are scoped specifically to enable full test suite compliance for RISC-V. * No changes impact other architectures. * The change to `transmute-scalar.rs` aligns with the intent of [[#143915](https://github.com/rust-lang/rust/pull/143915)](https://github.com/rust-lang/rust/pull/143915) and prevents architecture-dependent discrepancies during CI or local testing.
…r-errors Don't warn on never to any `as` casts as unreachable I'm doing this while being sleep deprived on a night train, let's hope this is coherent. Fixes rust-lang/rust#67227
…sts_on_sgx, r=Mark-Simulacrum [RTE-513] Ignore sleep_until test on SGX rust-lang/rust#141829 added a test for `sleep_until`: it checks whether its specification holds: > Puts the current thread to sleep until the specified deadline has passed. but in SGX there's no secure time source. There's only the ability to request the `insecure_time` from outside of the enclave through a [usercall](https://github.com/fortanix/rust-sgx/blob/master/intel-sgx/fortanix-sgx-abi/src/lib.rs#L590-L592) and the ability to [wait](https://github.com/rust-lang/rust/blob/master/library/std/src/sys/pal/sgx/abi/usercalls/mod.rs#L173-L179) for a certain event or timeout. But both are under the control of an attacker; users should not depend on the accuracy nor correctness of this time. We try to even enforce this by adding a +/-10% time interval to wait usercalls. The current `thread::sleep_until` implementation uses this `wait` usercall. When a negative randomization interval is added to the timeout passed in `wait`, the test fails. As users should not rely on the correctness of any time inside the enclave, it should be considered an incorrect test on SGX. This PR ignores this test.
…hercote overhaul `&mut` suggestions in borrowck errors * This refactors the logic so that it does not use fuzzy string matching for suggestions; it instead uses information directly from MIR. * If something comes from a custom `Index` impl for which the `IndexMut` trait does not apply, do not suggest adding `mut` after `&`. * Suggest `get_mut` with `unwrap` if error is fired on `BTreeMap` or `HashMap`. Supersedes rust-lang/rust#144018 cc ```@xizheyin``` Closes rust-lang/rust#143732
rework GAT borrowck limitation error The old one depends on the `ConstraintCategory` of the constraint which meant we did not emit this note if we had to prove the higher ranked trait bound due to e.g. normalization. This made it annoying brittle and caused MIR borrowck errors to be order dependent, fixes the issue in rust-lang/rust#140737 (comment). r? types cc ```@amandasystems```
take attr style into account in diagnostics when the original attribute was specified as an inner attribute, the suggestion will now match that attribute style
cleanup: use run_in_tmpdir in run-make/rustdoc-scrape-examples-paths We had an issue on our LLVM-head Rust builder where it got stuck with this test failing because it was reusing the tmpdir between runs and something broke the incremental compile. Everything seems to work fine with run_in_tmpdir in this test. tests/run-make/uefi-qemu also uses the same tmpdir across runs, but I don't have the right environment to test that so I didn't try fixing it. That is the only use of std::env::temp_dir left in run-make tests after this fix.
cg_llvm: Small cleanups to `owned_target_machine` This PR contains a few tiny cleanups to the `owned_target_machine` code. Each individual commit should be fairly straightforward.
Remove `LlvmArchiveBuilder` and supporting code/bindings Switching over to the newer Rust-based `ArArchiveBuilder` happened in rust-lang/rust#128936, a year ago. Per the comment in `new_archive_builder`, that seems like enough time to justify removing the older, unused `LlvmArchiveBuilder` implementation and its associated bindings. Fixes rust-lang/rust#128955.
Fix uplifting in `Assemble` step In rust-lang/rust#145310, I removed [this line](https://github.com/rust-lang/rust/pull/145310/files#diff-5a1e05f2688d271039171a547d407d0c8a96715ee64d35562fc76b4c9a874303L2109), which adjusted the stage of the build compiler if an uplift has happened. This broke stage3+ uplifted rustc builds (rust-lang/rust#145534). I could swear I tested this in the PR, but somehow I missed it. Instead of keeping the original returned stage, I made it more explicit by returning the actually used `build_compiler` from the `Rustc` step, and then use that in the `Assemble` step. The changes to `RustcLink` were needed to fix `ui-fulldeps`, which apparently build a stage3 rustc, because I haven't fixed the test steps yet 😅 Hopefully we might be able to remove `RustcLink` if the approach from rust-lang/rust#144252 will work. Should fix rust-lang/rust#145534. r? ``@jieyouxu``
…nkov Remove the `From` derive macro from prelude The new `#[derive(From)]` functionality (implemented in rust-lang/rust#144922) caused name resolution ambiguity issues (rust-lang/rust#145524). The reproducer looks e.g. like this: ```rust mod foo { pub use derive_more::From; } use foo::*; #[derive(From)] // ERROR: `From` is ambiguous struct S(u32); ``` It's pretty unfortunate that it works like this, but I guess that there's not much to be done here, and we'll have to wait for the next edition to put the `From` macro into the prelude. That will probably require rust-lang/rust#139493 to land. I created a new module in core (and re-exported it in std) called `from`, where I re-exported the `From` macro. I *think* that since this is a new module, it should not have the same backwards incompatibility issue. Happy to hear suggestions about the naming - maybe it would make sense as `core::macros::from::From`? But we already had a precedent in the `core::assert_matches` module, so I just followed suit. Fixes: rust-lang/rust#145524 r? ``@petrochenkov``
Improve context of bootstrap errors in CI Inspired by https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/printing.20test.20suite.20name.20by.20default/with/534920583, this PR attempts to improve the context displayed when a bootstrap invocation fails in CI. Since rust-lang/rust#145261, we now see the latest started step when a failure occurs. However, we can go further. 1) The first commit prints the actual executed bootstrap invocation command arguments when bootstrap ends. Since CI jobs often run multiple bootstrap commands, this makes it easier to figure out which one of them failed (before it was annoying having to search for that in CI logs). Because bootstrap doesn't really use `Result`s much, and most of them time it ends with the `detail_exit` function, which YOLOs `std::process::exit(...)`, I added the print there. 2) Adds `#[track_caller]` to a few bootstrap Cargo builder functions. This makes the log that we print when a command fails more accurate: ``` 2025-08-16T18:18:51.6998201Z Command ... failed ... 2025-08-16T18:18:51.7003653Z Created at: src/bootstrap/src/core/builder/cargo.rs:423:33 2025-08-16T18:18:51.7004032Z Executed at: src/bootstrap/src/core/build_steps/doc.rs:933:26 ``` Before, the `cargo.rs:XYZ` location wasn't very useful. 3) Is the most wild thing (I'll revert if you find it too magical). We store the step stack of the currently active `Builder` instance in a global variable, and when bootstrap exits with a failure, we print the stack, to make it easier to find out what was happening when a failure occurred. We could print an actual captured `Backtrace`, but I think that would be too much information in the common case. We now pass `RUST_BACKTRACE=1` on CI, so if bootstrap actually crashes unexpectedly, we would see the stacktrace. The end of the bootsrap failure log in CI now looks like this now: ``` Bootstrap failed while executing `x build library` ---BOOTSTRAP step stack start--- Assemble { target_compiler: Compiler { stage: 1, host: x86_64-unknown-linux-gnu, forced_compiler: false } } Rustc { target: x86_64-unknown-linux-gnu, build_compiler: Compiler { stage: 0, host: x86_64-unknown-linux-gnu, forced_compiler: false }, crates: [] } ---BOOTSTRAP step stack end--- ``` r? `@jieyouxu`
…iler-errors interpret: avoid forcing all integer newtypes into memory during clear_provenance While working on another PR I noticed locals moving into memory (via `force_allocation`) that I didn't expect to move there... turns out that is an issue I introduced when adding provenance clearing. This PR fixes that. r? `@oli-obk`
Rollup of 19 pull requests Successful merges: - rust-lang/rust#140956 (`impl PartialEq<{str,String}> for {Path,PathBuf}`) - rust-lang/rust#141744 (Stabilize `ip_from`) - rust-lang/rust#142681 (Remove the `#[no_sanitize]` attribute in favor of `#[sanitize(xyz = "on|off")]`) - rust-lang/rust#142871 (Trivial improve doc for transpose ) - rust-lang/rust#144252 (Do not copy .rmeta files into the sysroot of the build compiler during check of rustc/std) - rust-lang/rust#144476 (rustdoc-search: search backend with partitioned suffix tree) - rust-lang/rust#144567 (Fix RISC-V Test Failures in ./x test for Multiple Codegen Cases) - rust-lang/rust#144804 (Don't warn on never to any `as` casts as unreachable) - rust-lang/rust#144960 ([RTE-513] Ignore sleep_until test on SGX) - rust-lang/rust#145013 (overhaul `&mut` suggestions in borrowck errors) - rust-lang/rust#145041 (rework GAT borrowck limitation error) - rust-lang/rust#145243 (take attr style into account in diagnostics) - rust-lang/rust#145405 (cleanup: use run_in_tmpdir in run-make/rustdoc-scrape-examples-paths) - rust-lang/rust#145432 (cg_llvm: Small cleanups to `owned_target_machine`) - rust-lang/rust#145484 (Remove `LlvmArchiveBuilder` and supporting code/bindings) - rust-lang/rust#145557 (Fix uplifting in `Assemble` step) - rust-lang/rust#145563 (Remove the `From` derive macro from prelude) - rust-lang/rust#145565 (Improve context of bootstrap errors in CI) - rust-lang/rust#145584 (interpret: avoid forcing all integer newtypes into memory during clear_provenance) Failed merges: - rust-lang/rust#145359 (Fix bug where `rustdoc-js` tester would not pick the right `search.js` file if there is more than one) - rust-lang/rust#145573 (Add an experimental unsafe(force_target_feature) attribute.) r? `@ghost` `@rustbot` modify labels: rollup
Detect missing `derive` on unresolved attribute even when not imported
When encountering unresolved attributes, ensure the proc-macros for every crate in scope are added to the `macro_map` so that typos and missing `derive`s are properly detected.
```
error: cannot find attribute `sede` in this scope
--> $DIR/missing-derive-3.rs:20:7
|
LL | #[sede(untagged)]
| ^^^^
|
help: the derive macros `Deserialize` and `Serialize` accept the similarly named `serde` attribute
|
LL | #[serde(untagged)]
| +
error: cannot find attribute `serde` in this scope
--> $DIR/missing-derive-3.rs:14:7
|
LL | #[serde(untagged)]
| ^^^^^
|
note: `serde` is imported here, but it is a crate, not an attribute
--> $DIR/missing-derive-3.rs:4:1
|
LL | extern crate serde;
| ^^^^^^^^^^^^^^^^^^^
help: `serde` is an attribute that can be used by the derive macros `Deserialize` and `Serialize`, you might be missing a `derive` attribute
|
LL + #[derive(Deserialize, Serialize)]
LL | enum B {
|
```
Follow up to rust-lang/rust#134841. Fix rust-lang/rust#47608.
…rors actually provide the correct args to coroutine witnesses rust-lang/rust#145194 accidentally provided all arguments of the closure to the witness, but the witness only takes the generic parameters of the defining scope: https://github.com/rust-lang/rust/blob/216cdb7b22b637cef75b7225c642cb7587192643/compiler/rustc_hir_typeck/src/closure.rs#L164 Fixes rust-lang/rust#145288
…nszelmann Couple of codegen_fn_attrs improvements As noted in rust-lang/rust#144678 (comment) here is no need to keep link_name and export_name separate, which the third commit fixes by merging them. The second commit removes some dead code and the first commit merges two ifs with equivalent conditions. The last commit is an unrelated change which removes an unused `feature(autodiff)`.
Do not strip binaries in bootstrap everytime if they are unchanged I was profiling bootstrap to figure out why a no-op build takes upward of two seconds on my machine. I found that half of that is Cargo (which is mostly unavoidable) and the rest (~900ms) is running strip. We don't need to restrip already stripped binaries all the time. r? `@jieyouxu`
…w, r=ibraheemdev Stabilize `const_pathbuf_osstring_new` feature This closes [tracking issue](rust-lang/rust#141520) and stabilises `{OsString, PathBuf}::new` in const
Properly recover from parenthesized use-bounds (precise capturing lists) plus small cleanups Fixes rust-lang/rust#145470. First commit fixes the issue, second one performs some desperately needed cleanups. The fix shouldn't be a breaking change because IINM the parser always ensures that all brackets are balanced (via a buffer of brackets). Meaning even though we used to accept `(use<>` as a valid precise capturing list, it was guaranteed that we would fail in the end.
…, r=Mark-Simulacrum [Debuginfo] improve enum value formatting in LLDB for better readability > TL;DR: When debugging with CodeLLDB, I noticed enum values were often hard to read because LLDB lists every possible variant, resulting in a verbose and cluttered view, even though only one variant is actually valid. Interestingly, raw enum types display nicely. After some investigation, I found that `&enum` values get classified as `Other`, so it falls back to `DefaultSyntheticProvider`, which causes this verbose output. ## What does this PR do? This PR contains 2 commits: 1. change the enum value formatting from showing 2 separate fields (`value` for attached data and `$discr$` for the discriminator) to a concise `<readable variant name>: <attached data>` format 2. dereference pointer types in `classify_rust_type` so that it can return more accurate type for reference type ## Self-test proof Before: <img width="1706" height="799" alt="before" src="https://github.com/user-attachments/assets/b66c7e22-990a-4da5-9036-34e3f9f62367" /> After: <img width="1541" height="678" alt="after" src="https://github.com/user-attachments/assets/36db32e2-f822-4883-8f17-cb8067e509f6" />
Add codegen-llvm regression tests Most of these regressions deal with elimination of panics and bounds checks that were fixed upstream by LLVM. closes rust-lang/rust#141497 closes rust-lang/rust#131162 closes rust-lang/rust#129583 closes rust-lang/rust#110971 closes rust-lang/rust#91109 closes rust-lang/rust#80075 closes rust-lang/rust#74917 closes rust-lang/rust#71997 closes rust-lang/rust#71257 closes rust-lang/rust#59352
Fix some typos in LocalKey documentation A few minor grammatical/wording changes in the `std::thread::LocalKey` documentation.
doc: fix some typos in comment fix some typos in comment
tests: Ignore basic-stepping.rs on LoongArch
Refactor lint buffering to avoid requiring a giant enum Lint buffering currently relies on a giant enum `BuiltinLintDiag` containing all the lints that might potentially get buffered. In addition to being an unwieldy enum in a central crate, this also makes `rustc_lint_defs` a build bottleneck: it depends on various types from various crates (with a steady pressure to add more), and many crates depend on it. Having all of these variants in a separate crate also prevents detecting when a variant becomes unused, which we can do with a dedicated type defined and used in the same crate. Refactor this to use a dyn trait, to allow using `LintDiagnostic` types directly. Because the existing `BuiltinLintDiag` requires some additional types in order to decorate some variants, which are only available later in `rustc_lint`, use an enum `DecorateDiagCompat` to handle both the `dyn LintDiagnostic` case and the `BuiltinLintDiag` case. --- With the infrastructure in place, use it to migrate three of the enum variants to use `LintDiagnostic` directly, as a proof of concept and to demonstrate that the net result is a reduction in code size and a removal of a boilerplate-heavy layer of indirection. Also remove an unused `BuiltinLintDiag` variant.
fix(lexer): Allow '-' in the frontmatter infostring continue set This more closely matches the RFC and what our T-lang contact has asked for, see rust-lang/rust#136889 (comment) Tracking issue: rust-lang/rust#136889
Add aarch64_be-unknown-hermit target Follow-up to rust-lang/rust#144962, which added the target necessary to build the Hermit bootloader and kernel for `aarch64_be`. This adds the target for Rust applications that can run in Hermit. I've been testing this for a while now and `@mkroening` and `@stlankes` are on board with adding this target. About the [tier 3 target policy](https://doc.rust-lang.org/rustc/target-tier-policy.html#tier-3-target-policy): > - A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) The maintainers for this target are the same as for the other Hermit targets, `@mkroening` and `@stlankes.` > - Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target. > - Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it. > - If possible, use only letters, numbers, dashes and underscores for the name. Periods (.) are known to cause issues in Cargo. The target name is consistent with the existing `aarch64-unknown-hermit` target and the existing big endian aarch64 targets like `aarch64_be-unknown-linux-gnu`. > - Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. > - The target must not introduce license incompatibilities. > - Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). > - The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. > - Compiling, linking, and emitting functional binaries, libraries, or other code for the target (whether hosted on the target itself or cross-compiling from another target) must not depend on proprietary (non-FOSS) libraries. Host tools built for the target itself may depend on the ordinary runtime libraries supplied by the platform and commonly used by other applications built for the target, but those libraries must not be required for code generation for the target; cross-compilation to the target must not require such libraries at all. For instance, rustc built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3. > - "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are not limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. There are no licensing issues or proprietary components required to compile for this target. > - Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions. > - This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements. Ack. > - Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. This target implements std with the same featureset as `aarch64-unknown-hermit`. > - The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary. Ack, that is part of the markdown document. > - Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages. > - Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. Ack. > - Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. > - In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target. This doesn't break any existing targets. > - Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target. (Having support in a fork of the backend is not sufficient, it must be upstream.) The LLVM backend works. > - If a tier 3 target stops meeting these requirements, or the target maintainers no longer have interest or time, or the target shows no signs of activity and has not built for some time, or removing the target would improve the quality of the Rust codebase, we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target), to check potential interest in improving the situation. Ack. r? compiler_leads
convert strings to symbols in attr diagnostics r? `@lcnr` As you rightfully noticed in rust-lang/rust#145670
Ship LLVM tools for the correct target when cross-compiling The LLVM config returned from the `Llvm` step in bootstrap was always the *host* LLVM config (as we cannot execute the cross-compiled LLVM config). But this wasn't obvious in bootstrap before (there was just a comment about it, but that's it), which caused a bug where bootstrap was copying LLVM tools from the host target to the cross-compiled rustc sysroot. This was probably happening for quite a long time, we just haven't noticed before. Note that I consider this to be mostly a hotfix, I plan to refactor the LLVM handling in bootstrap soon-ish to make it harder to misuse and be better in general. Fixes: rust-lang/rust#145699
Revert suggestions for missing methods in tuples As requested by `@estebank` and as discussed with `@jackh726,` this reverts rust-lang/rust#142034 because of diagnostics ICEs like rust-lang/rust#142488 and its duplicates that have reached stable by now. We will work on a proper fix to reland this cool work in the near future, but in the meantime, a revert is safer to validate and backport to beta and stable, so here it is.
Rollup of 28 pull requests Successful merges: - rust-lang/rust#132087 (Fix overly restrictive lifetime in `core::panic::Location::file` return type) - rust-lang/rust#137396 (Recover `param: Ty = EXPR`) - rust-lang/rust#137457 (Fix host code appearing in Wasm binaries) - rust-lang/rust#142185 (Convert moves of references to copies in ReferencePropagation) - rust-lang/rust#144648 (Implementation: `#[feature(nonpoison_rwlock)]`) - rust-lang/rust#144897 (print raw lifetime idents with r#) - rust-lang/rust#145218 ([Debuginfo] improve enum value formatting in LLDB for better readability) - rust-lang/rust#145380 (Add codegen-llvm regression tests) - rust-lang/rust#145573 (Add an experimental unsafe(force_target_feature) attribute.) - rust-lang/rust#145597 (resolve: Remove `ScopeSet::Late`) - rust-lang/rust#145633 (Fix some typos in LocalKey documentation) - rust-lang/rust#145641 (On E0277, point at type that doesn't implement bound) - rust-lang/rust#145669 (rustdoc-search: GUI tests check for `//` in URL) - rust-lang/rust#145695 (Introduce ProjectionElem::try_map.) - rust-lang/rust#145710 (Fix the ABI parameter inconsistency issue in debug.rs for LoongArch64) - rust-lang/rust#145726 (Experiment: Reborrow trait) - rust-lang/rust#145731 (Make raw pointers work in type-based search) - rust-lang/rust#145736 (triagebot: Update style team reviewers) - rust-lang/rust#145738 (Uplift rustc_mir_transform::coverage::counters::union_find to rustc_data_structures.) - rust-lang/rust#145742 (rustdoc js: Even more typechecking improvments ) - rust-lang/rust#145743 (doc: fix some typos in comment) - rust-lang/rust#145745 (tests: Ignore basic-stepping.rs on LoongArch) - rust-lang/rust#145747 (Refactor lint buffering to avoid requiring a giant enum) - rust-lang/rust#145751 (fix(lexer): Allow '-' in the frontmatter infostring continue set) - rust-lang/rust#145761 (Add aarch64_be-unknown-hermit target) - rust-lang/rust#145762 (convert strings to symbols in attr diagnostics) - rust-lang/rust#145763 (Ship LLVM tools for the correct target when cross-compiling) - rust-lang/rust#145765 (Revert suggestions for missing methods in tuples) r? `@ghost` `@rustbot` modify labels: rollup
Only scan each definition once for dead-code. r? `@ghost`
Update cargo submodule 12 commits in 71eb84f21aef43c07580c6aed6f806a6299f5042..623d536836b4cde09ce38609232a024d5b25da81 2025-08-17 17:18:56 +0000 to 2025-08-22 19:05:52 +0000 - test(frontmatter): Match test updates in rustc (rust-lang/cargo#15878) - chore: fix some typos in comment (rust-lang/cargo#15877) - Add Arm64 Windows CI jobs (rust-lang/cargo#15790) - suggest workspace hints for boolean dependencies (rust-lang/cargo#15507) - make `UnitGenerator` public in cargo-as-a-library (rust-lang/cargo#15873) - Linting system (rust-lang/cargo#15865) - Switch to using native mdbook fragment redirects (rust-lang/cargo#15861) - docs(profile): revert wrong statement of lto options' optimization (rust-lang/cargo#15855) - docs: avoid ambiguity between update and fetch (rust-lang/cargo#15860) - docs: mention how Cargo fetch git submodules (rust-lang/cargo#15853) - feat(unstable): Added `-Zbuild-dir-new-layout` unstable feature (rust-lang/cargo#15848) - Implement `host`-target substitution (rust-lang/cargo#15838) r? ghost
Weekly `cargo update` (with libc pin) Supersedes rust-lang/rust#145516 Manually pins libc for `compiler` and `rustbook` (both of which use rustix), with fixmes to remove this later. ``` compiler & tools dependencies: Locking 28 packages to latest compatible versions Updating anyhow v1.0.98 -> v1.0.99 Updating bitflags v2.9.1 -> v2.9.2 Updating clap v4.5.43 -> v4.5.45 Updating clap_builder v4.5.43 -> v4.5.44 Updating clap_derive v4.5.41 -> v4.5.45 Updating curl v0.4.48 -> v0.4.49 Updating curl-sys v0.4.82+curl-8.14.1 -> v0.4.83+curl-8.15.0 Updating cxx v1.0.166 -> v1.0.168 Updating cxx-build v1.0.166 -> v1.0.168 Updating cxxbridge-cmd v1.0.166 -> v1.0.168 Updating cxxbridge-flags v1.0.166 -> v1.0.168 Updating cxxbridge-macro v1.0.166 -> v1.0.168 Updating glob v0.3.2 -> v0.3.3 Updating object v0.37.2 -> v0.37.3 Updating proc-macro2 v1.0.95 -> v1.0.101 Updating rayon v1.10.0 -> v1.11.0 Updating rayon-core v1.12.1 -> v1.13.0 Updating serde-untagged v0.1.7 -> v0.1.8 Updating socket2 v0.5.10 -> v0.6.0 Updating syn v2.0.104 -> v2.0.106 Updating thiserror v2.0.12 -> v2.0.15 Updating thiserror-impl v2.0.12 -> v2.0.15 Updating uuid v1.17.0 -> v1.18.0 Updating wasm-encoder v0.236.0 -> v0.236.1 Updating wasmparser v0.236.0 -> v0.236.1 Updating wast v236.0.0 -> v236.0.1 Updating wat v1.236.0 -> v1.236.1 note: pass `--verbose` to see 35 unchanged dependencies behind latest library dependencies: Locking 2 packages to latest compatible versions Updating libc v0.2.174 -> v0.2.175 Updating object v0.37.2 -> v0.37.3 note: pass `--verbose` to see 2 unchanged dependencies behind latest rustbook dependencies: Locking 13 packages to latest compatible versions Updating anyhow v1.0.98 -> v1.0.99 Updating bitflags v2.9.1 -> v2.9.2 Updating cc v1.2.32 -> v1.2.33 Updating clap v4.5.43 -> v4.5.45 Updating clap_builder v4.5.43 -> v4.5.44 Updating clap_complete v4.5.56 -> v4.5.57 Updating clap_derive v4.5.41 -> v4.5.45 Updating proc-macro2 v1.0.95 -> v1.0.101 Updating syn v2.0.104 -> v2.0.106 Updating terminal_size v0.4.2 -> v0.4.3 Updating thiserror v2.0.12 -> v2.0.15 Updating thiserror-impl v2.0.12 -> v2.0.15 ```
change HIR typeck region uniquification handling approach rust-lang/rust#144405 causes structural lookup of opaque types to not work during HIR typeck, so instead avoid uniquifying goals and instead only reprove them if MIR borrowck actually encounters an error. This doesn't perfectly maintain the property that HIR typeck succeeding implies that MIR typeck succeeds, instead weakening this check to only guarantee that HIR typeck implies that MIR typeck succeeds modulo region uniquification. This means we still get the actually desirable ICEs if we MIR building is broken or we forget to check some property in HIR typeck, without having to deal with the fallout of uniquification in HIR typeck itself. We report errors using the original obligation sources of HIR typeck so diagnostics aren't that negatively impacted either. Here's the history of region uniquification while working on the new trait solver: - rust-lang/rust#107981 - rust-lang/rust#110180 - rust-lang/rust#114117 - rust-lang/rust#130821 - rust-lang/rust#144405 - rust-lang/rust#145706 <- we're here 🎉 r? `@BoxyUwU`
Fix `LazyLock` poison panic message Fixes the issue raised in rust-lang/rust#144872 (comment) r? ```@Amanieu```
rustc-dev-guide subtree update Subtree update of `rustc-dev-guide` to c221508. Created using https://github.com/rust-lang/josh-sync. r? ```@ghost```
Use unnamed lifetime spans as primary spans for `MISMATCHED_LIFETIME_SYNTAXES` Fixes rust-lang/rust#145772 This PR changes the primary span(s) of the `MISMATCHED_LIFETIME_SYNTAXES` to point to the *unnamed* lifetime spans in both the inputs and *outputs* of the function signature. As reported in rust-lang/rust#145772, this should make it so that IDEs highlight the spans of the actionable part of this lint, rather than just the (possibly named) input spans like they do today. This could be tweaked further perhaps, for example for `fn foo(_: T<'_>) -> T`, we don't need to highlight the elided lifetime if the actionable part is to change only the return type to `T<'_>`, but I think it's improvement on what's here today, so I think that should be follow-up since I think the logic might get a bit hairy. cc ```@shepmaster```
std/src/lib.rs: mention "search button" instead of "search bar" r? ```@GuillaumeGomez```
Rollup of 5 pull requests Successful merges: - rust-lang/rust#144531 (Add lint against integer to pointer transmutes) - rust-lang/rust#145307 (Fix `LazyLock` poison panic message) - rust-lang/rust#145554 (rustc-dev-guide subtree update) - rust-lang/rust#145798 (Use unnamed lifetime spans as primary spans for `MISMATCHED_LIFETIME_SYNTAXES`) - rust-lang/rust#145799 (std/src/lib.rs: mention "search button" instead of "search bar") r? `@ghost` `@rustbot` modify labels: rollup
Add more tests for the parallel rustc At the moment, the parallel frontend test cases are severely lacking. Althought some reported issues have been resolved, they haven't been added into the tests. This PR arranges the resolved ICE issues and adds tests for them. Whether it is worthwhile to add a separate test suite for the paralel frontend still requires futher discussion. But we are trying coveraging issues being resolved through capability of the existing UI test suite. Discussion: [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/233931-t-compiler.2Fmajor-changes/topic/Proposal.20for.20a.20dedicated.20test.20suite.20for.20t.E2.80.A6.20compiler-team.23906) Related issues: - rust-lang/rust#120760 - rust-lang/rust#124423 fixed by rust-lang/rust#140358 - rust-lang/rust#127971 fxied by rust-lang/rust#140358 - rust-lang/rust#120601 fixed by rust-lang/rust#127311 cc `@jieyouxu`
…ion, r=GuillaumeGomez rustdoc: render attributes in Field and Variants sections Follow up to rust-lang/rust#145782. Render attributes in Field and Variants sections. Associated constants and methods are already rendered with attributes in their sections, so I figured out fields and variants should too. (no change here) <img width="378" height="265" alt="image" src="https://github.com/user-attachments/assets/b4f45c42-0146-486e-8881-138d2a7ad1c4" /> r? `@GuillaumeGomez` --- Before (left) / after (right): <img width="396" height="519" alt="image" src="https://github.com/user-attachments/assets/18288e13-09e7-448c-ba98-2023fa6df597" /> <img width="382" height="597" alt="image" src="https://github.com/user-attachments/assets/e624dc84-d169-41cc-bb89-7a1c2b2bb3e3" /> <img width="371" height="313" alt="image" src="https://github.com/user-attachments/assets/29833645-0b93-4900-80a8-c5a1e0b541b4" /> <img width="371" height="331" alt="image" src="https://github.com/user-attachments/assets/d5ce4b9e-f7f1-4f36-8ac0-08b0b5077e48" /> <img width="362" height="309" alt="image" src="https://github.com/user-attachments/assets/0436a51d-29a5-4403-a27c-7697524f807a" /> <img width="357" height="332" alt="image" src="https://github.com/user-attachments/assets/9a759fc5-30e7-4bbb-a88a-a3e3d1ed02aa" />
Add support for macro expansion in rustdoc source code pages This is what it looks like:   You can test it [here](https://rustdoc.crud.net/imperio/macro-expansion/src/lib/lib.rs.html). In this case, I also enabled the `--generate-link-to-definition` to show that both options work well together. Note: <del>There is a bug currently in firefox where the line numbers are not displayed correctly if they're inside the "macro expansion" span: https://bugzilla.mozilla.org/show_bug.cgi?id=1949948<del> Found a workaround around this bug. r? `@notriddle`
This updates the rust-version file to a1dbb443527bd126452875eb5d5860c1d001d761.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: a1dbb443527bd126452875eb5d5860c1d001d761 Filtered ref: c233904 This merge was created using https://github.com/rust-lang/josh-sync.
|
Thanks for the PR. If you have write access, feel free to merge this PR if it does not need reviews. You can request a review using |
rustbot
added
the
S-waiting-on-review
rustbot
removed
the
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Latest update from rustc.