Lazy-ify some markdown rendering
Seems to have a positive effect in my local perf runs 😍
r? `@GuillaumeGomez` if you're interested, otherwise feel free to reassign
(would also love a perf run)
Remove let_chains unstable feature
Per https://github.com/rust-lang/rust/issues/53667#issuecomment-3016742982 (but then I also noticed rust-lang/rust#140722)
This replaces the feature gate with a parser error that says let chains require 2024.
A lot of tests were using the unstable feature. I either added edition:2024 to the test or split out the parts that require 2024.
Add new self-profiling event to cheaply aggregate query cache hit counts
Self-profile can record various types of things, some of them are not enabled, like query cache hits. Rustc currently records cache hits as "instant" measureme events, which records the thread ID, current timestamp, and constructs an individual event for each such cache hit. This is incredibly expensive, in a small hello world benchmark that just depends on serde, it makes compilation with nightly go from ~3s (with `-Zself-profile`) to ~15s (with `-Zself-profile -Zself-profile-events=default,query-cache-hit`).
We'd like to add query cache hits to rustc-perf (https://github.com/rust-lang/rustc-perf/pull/2168), but there we only need the actualy cache hit counts, not the timestamp/thread ID metadata associated with it.
This PR adds a new `query-cache-hit-count` event. Instead of generating individual instant events, it simply aggregates cache hit counts per *query invocation* (so a combination of a query and its arguments, if I understand it correctly) using an atomic counter. At the end of the compilation session, these counts are then dumped to the self-profile log using integer events (in a similar fashion as how we record artifact sizes). I suppose that we could dedup the query invocations in rustc directly, but I don't think it's really required. In local experiments with the hello world + serde case, the query invocation records generated ~30 KiB more data in the self-profile, which was ~10% increase in this case.
With this PR, the overhead of `-Zself-profile` seems to be the same as before, at least on my machine, so I also enabled query cache hit counts by default when self profiling is enabled.
We should also modify `analyzeme`, specifically [this](https://github.com/rust-lang/measureme/blob/master/analyzeme/src/analysis.rs#L139), and make it load the integer events with query cache hit counts. I can do that as a follow-up, it's not required to be done in sync with this PR, and it doesn't require changes in rustc.
CC `@cjgillot`
r? `@oli-obk`
Start moving wf checking away from HIR
I'm trying to only access the HIR in the error path. My hope is that once we move significant portions of wfcheck off HIR that incremental will be able to cache wfcheck queries significantly better.
I think I am reaching a blocker because we normally need to provide good spans to `ObligationCause`, so that the trait solver can report good errors. In some cases I have been able to use bad spans and improve them depending on the `ObligationCauseCode` (by loading HIR in the case where we actually want to error). To scale that further we'll likely need to remove spans from the `ObligationCause` entirely (leaving it to some variants of `ObligationCauseCode` to have a span when they can't recompute the information later). Unsure this is the right approach, but we've already been using it. I will create an MCP about it, but that should not affect this PR, which is fairly limited in where it does those kind of tricks.
Especially b862d8828e is interesting here, because I think it improves spans in all cases
Port `#[rustc_layout_scalar_valid_range_start/end]` to the new attrib…
Ports `rustc_layout_scalar_valid_range_start` and `rustc_layout_scalar_valid_range_end` to the new attribute parsing infrastructure for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971353197
r? `@jdonszelmann`
Introduce `ByteSymbol`
It's like `Symbol` but for byte strings. The interner is now used for both `Symbol` and `ByteSymbol`. E.g. if you intern `"dog"` and `b"dog"` you'll get a `Symbol` and a `ByteSymbol` with the same index and the characters will only be stored once.
The motivation for this is to eliminate the `Arc`s in `ast::LitKind`, to make `ast::LitKind` impl `Copy`, and to avoid the need to arena-allocate `ast::LitKind` in HIR. The latter change reduces peak memory by a non-trivial amount on literal-heavy benchmarks such as `deep-vector` and `tuple-stress`.
`Encoder`, `Decoder`, `SpanEncoder`, and `SpanDecoder` all get some changes so that they can handle normal strings and byte strings.
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#143019 (Ensure -V --verbose processes both codegen_backend and codegen-backend)
- rust-lang/rust#143140 (give Pointer::into_parts a more scary name and offer a safer alternative)
- rust-lang/rust#143175 (Make combining LLD with external LLVM config a hard error)
- rust-lang/rust#143180 (Use `tracing-forest` instead of `tracing-tree` for bootstrap tracing)
- rust-lang/rust#143223 (Improve macro stats printing)
- rust-lang/rust#143228 (Handle build scripts better in `-Zmacro-stats` output.)
- rust-lang/rust#143229 ([COMPILETEST-UNTANGLE 1/N] Move some some early config checks to the lib and move the compiletest binary)
- rust-lang/rust#143246 (Subtree update of `rust-analyzer`)
- rust-lang/rust#143248 (Update books)
r? `@ghost`
`@rustbot` modify labels: rollup
Update books
## rust-lang/book
2 commits in 8a6d44e45b7b564eeb6bae30507e1fbac439d72d..ef1ce8f87a8b18feb1b6a9cf9a4939a79bde6795
2025-06-28 18:06:08 UTC to 2025-06-26 23:08:19 UTC
- Chapter 14 from tech review (rust-lang/book#4423)
- Chapter 13 from tech review (rust-lang/book#4421)
## rust-embedded/book
1 commits in 10fa1e084365f23f24ad0000df541923385b73b6..41f688a598a5022b749e23d37f3c524f6a0b28e1
2025-06-27 07:21:31 UTC to 2025-06-27 07:21:31 UTC
- Fix incorrect type for semihosted stdout stream rust-lang/rust#394 (rust-embedded/book#395)
## rust-lang/reference
4 commits in 50fc1628f36563958399123829c73755fa7a8421..e9fc99f107840813916f62e16b3f6d9556e1f2d8
2025-06-28 20:00:14 UTC to 2025-06-24 19:02:48 UTC
- fix: swap places for 2 words in associated-items.md sentence. (rust-lang/reference#1871)
- Add new temporary lifetime extension rule (rust-lang/reference#1813)
- Fix smart punctuation inside grammar terminals (rust-lang/reference#1869)
- Fix placement of codegen link definitions (rust-lang/reference#1868)
## rust-lang/rust-by-example
1 commits in 05c7d8bae65f23a1837430c5a19be129d414f5ec..288b4e4948add43f387cad35adc7b1c54ca6fe12
2025-06-25 12:35:59 UTC to 2025-06-25 12:35:59 UTC
- allow easy fixes (rust-lang/rust-by-example#1941)
Only compute recursive callees once.
Inlining MIR in a cyclic call graph may create query cycles, which are ICEs. The current implementation `mir_callgraph_reachable(inlining_candidate, being_optimized)` checks if calling `inlining_candidate` may cycle back to `being_optimized` that we are currently inlining into.
This PR replaces this device with query `mir_callgraph_cyclic(being_optimized)` which searches the call graph for all cycles going back to `being_optimized`, and returns the set of functions involved in those cycles.
This is a tradeoff:
- in the current implementation, we perform more walks, but shallower;
- in this new implementation, we perform fewer walks, but exhaust the graph.
I'd have liked to compute this using some kind of SCC, but generic parameters make resolution path-dependent, so usual graph algorithms do not apply.
Insert checks for enum discriminants when debug assertions are enabled
Similar to the existing null-pointer and alignment checks, this checks for valid enum discriminants on creation of enums through unsafe transmutes. Essentially this sanitizes patterns like the following:
```rust
let val: MyEnum = unsafe { std::mem::transmute<u32, MyEnum>(42) };
```
An extension of this check will be done in a follow-up that explicitly sanitizes for extern enum values that come into Rust from e.g. C/C++.
This check is similar to Miri's capabilities of checking for valid construction of enum values.
This PR is inspired by saethlin@'s PR
https://github.com/rust-lang/rust/pull/104862. Thank you so much for keeping this code up and the detailed comments!
I also pair-programmed large parts of this together with vabr-g@.
r? `@saethlin`
Stop collecting unmentioned constants
This avoids generating useless dead LLVM IR. This appears to have regressed and/or been introduced in rust-lang/rust#53821 (unfortunately a very large PR - I don't see any direct discussion there of this particular change), but as far as I can tell is at least no longer necessary -- or we lack test coverage -- because none of our UI tests indicate diagnostics regressions. The adjusted codegen-units test has comments explicitly noting that these items should *not* be collected ("These are not referenced, so they do not produce mono-items").
I noticed this while looking at libcore LLVM IR we generate, which contained dead code references to the NOOP Waker item, which is never used inside libcore. Producing LLVM IR for it during libcore's compilation, only for that IR to get deleted by LLVM as unused, isn't useful. Note that the IR is generally all marked internal, too.
Enforce in bootstrap that build must have stage at least 1
This PR is a step towards https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Proposal.20to.20cleanup.20stages.20and.20steps.20after.20the.20redesign/with/523586917. It's very hard or me to make self-contained changes to bootstrap at this moment, so this PR kind of does several things:
1) (first two commits) Try to reduce the usage of `Std::new` in bootstrap, and replace it with a `Builder::std` method (similar to `Builder::compiler`). This is mostly to remove executions of the `Std` step for stage 0, which doesn't make a lot of sense; I'd like to ideally have the invariant that when a step is invoked, it actually builds or does something. Eventually, I'd like for everything to go through `Builder::std`. (Note: I'm not totally married to this idea, if you don't like it, we can remove it from this PR. I mostly did it right now to remove stage 0 std steps from snapshot tests, which shouldn't be there, but we can also filter them out in a different way)
2) Make sure that when you pass `x build compiler`, only the `Assemble` root level step will be invoked, and not the `Rustc` step. Before, both were invoked, which actually ran `Rustc` twice, once with all `crates` filled, and once with no crates (but both actually represent the same situation). Since the `Rustc::make_run` step actually requests a compile that is one stage below it, this actually made `build compiler --stage 0` work, which we don't want to have anymore.
3) Enforce a bootstrap-global invariant that all `build` commands are always on stage `>=1`. If you try to `build` anything on stage 0, it will print a warning and exit bootstrap. This follows the intuition from the new staging rules after the stage redesign; artifacts that are "stage 0" come outside of bootstrap, and we can't really build something for which we don't have source (although we can still test it, but that's for another PR).
Now the logic for build should be quite simple. For pretty much everything except for `Std`, you first use the stage0 compiler to build stage 1. Then you can build a stage 2 <something> using the previously built stage 1 (and then you can continue to stage 3 etc.). And that's it. The default build stage for everything is 1 (modulo download-ci-rustc, but that's a separate can of worms).
The snapshot test infra isn't super nice at the moment, as one of next steps I want to create some simple Builder pattern that will allow us to configure the bootstrap invocations in a more "forward-compatible" way (e.g. now it's not possible to modify the config passed to `configure_with_args`).
There are some things not yet fully resolved for build stage 0:
1) Cargo is still a `ModeRustc` tool, even though it doesn't really have to be, it is buildable with the stage0 compiler
2) bootstrap tools (`opt-dist`, `build-manifest` etc.) are still called stage0 tools, and in the bootstrap output it says something like "stage 0 rustc builds stage 0 opt-dist". Which is a bit weird, but functionally there's no difference, it's just a slightly inconsistent output. We still haven't decided if we should make these tools ignore staging altogether (which is IMO the right choice) or if we want to allow building stage 1/2/3/... bootstrap tools.
r? `@jieyouxu`
try-job: x86_64-rust-for-linux
Turn `stdarch` into a Josh subtree
In a similar vein as https://github.com/rust-lang/rust/pull/141229, this PR makes the `stdarch` repository a Josh subtree (it was previously a submodule). The initial commit of `stdarch` upon this is based is `5a7342fc16b208b1b16624e886937ed8509a6506`, which is the previous commit SHA of the `stdarch` submodule. The sync was performed according to https://hackmd.io/7pOuxnkdQDaL1Y1FQr65xg.
This was decided in https://github.com/rust-lang/stdarch/issues/1655.
Test pull PR on my fork: https://github.com/Kobzol/stdarch/pull/1
Test push PR on my fork: https://github.com/Kobzol/rust/pull/59
I plan to use the same Rust (miri-inspired) tooling that we use for `rustc-dev-guide` to enable pulls/pushes on stdarch.
Note that this repository currently doesn't have any stdarch-specific tests, so before that, the subtree should only be modified through this repository only when dealing with changes that contain "cyclical dependencies" between stdarch and rustc. The long term vision is to integrate stdarch into rust-lang/rust completely.
CC `@Amanieu`
try-job: aarch64-apple
try-job: aarch64-gnu
try-job: `x86_64-msvc-*`
try-job: x86_64-gnu
try-job: x86_64-gnu-aux
