Add profiling of bootstrap commands using Chrome events
Since we now have support for tracing in bootstrap, and the execution of most commands is centralized within a few functions, it's quite trivial to also trace command execution, and visualize it using the Chrome profiler. This can be helpful both to profile what takes time in bootstrap and also to get a visual idea of what happens in a given bootstrap invocation (since the execution of external commands is usually the most interesting thing).
This is how it looks:

I first tried to use [tracing-flame](https://github.com/tokio-rs/tracing/tree/master/tracing-flame), but the output wasn't very useful, because the event/stackframe names were bootstrap code locations, instead of the command contents.
r? ``@jieyouxu``
Compiletest should not inherit all host RUSTFLAGS
I told ``@rhelmot`` to do this in #134913. But it's not correct; compiletest shouldn't inherit RUSTFLAGS at all.
Pass a single new --host-rustcflags to compiletest instead, without overwriting any existing arguments.
Fixes the following failure, which only happens when building llvm from source and then running `x test --stage 1 ui-fulldeps`:
```
diff --git a/tests/ui-fulldeps/fluent-messages/test.stderr b/tests/ui-fulldeps/fluent-messages/test.stderr
index 0b3bb14ce51..978ac46c5a2 100644
--- a/tests/ui-fulldeps/fluent-messages/test.stderr
+++ b/tests/ui-fulldeps/fluent-messages/test.stderr
``@@`` -1,3 +1,8 ``@@``
+warning[E0602]: unknown lint: `linker_messages`
+ |
+ = note: requested on the command line with `-A linker_messages`
+ = note: `#[warn(unknown_lints)]` on by default
```
See https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/.E2.9C.94.20unknown.20lint.3A.20.60linker_messages.60.20when.20blessing.20tests.20on.20.2E.2E.2E for more context.
valtree performance tuning
Summary: This PR makes type checking of code with many type-level constants faster.
After https://github.com/rust-lang/rust/pull/136180 was merged, we observed a small perf regression (https://github.com/rust-lang/rust/pull/136318#issuecomment-2635562821). This happened because that PR introduced additional copies in the fast reject code path for consts, which is very hot for certain crates: 6c1d960d88/compiler/rustc_type_ir/src/fast_reject.rs (L486-L487)
This PR improves the performance again by properly interning the valtrees so that copying and comparing them becomes faster. This will become especially useful with `feature(adt_const_params)`, so the fast reject code doesn't have to do a deep compare of the valtrees.
Note that we can't just compare the interned consts themselves in the fast reject, because sometimes `'static` lifetimes in the type are be replaced with inference variables (due to canonicalization) on one side but not the other.
A less invasive alternative that I considered is simply avoiding copies introduced by https://github.com/rust-lang/rust/pull/136180 and comparing the valtrees it in-place (see commit: 9e91e50ac5 / perf results: https://github.com/rust-lang/rust/pull/136593#issuecomment-2642303245), however that was still measurably slower than interning.
There are some minor regressions in secondary benchmarks: These happen due to changes in memory allocations and seem acceptable to me. The crates that make heavy use of valtrees show no significant changes in memory usage.
"stage 1" for fulldeps means "compile with stage 0, link against stage 1".
But this code wanted to switch on the compiler that's building, not the
compiler that's being tested. Fix the check.
Previously, it would fail with a warning about linker-messages:
```
--- stderr -------------------------------
warning[E0602]: unknown lint: `linker_messages`
|
= note: requested on the command line with `-A linker_messages`
= note: `#[warn(unknown_lints)]` on by default
```
Parallel-compiler-related cleanup
Parallel-compiler-related cleanup
I carefully split changes into commits. Commit messages are self-explanatory. Squashing is not recommended.
cc "Parallel Rustc Front-end" https://github.com/rust-lang/rust/issues/113349
r? SparrowLii
``@rustbot`` label: +WG-compiler-parallel
I told rhelmot to do this in #134913. But it's not correct; compiletest
shouldn't inherit RUSTFLAGS at all.
Pass a single new --host-rustcflags to compiletest instead, without overwriting any
existing arguments.
Fixes the following failure, which only happens when building llvm from
source and then running `x test --stage 1 ui-fulldeps`:
```
diff --git a/tests/ui-fulldeps/fluent-messages/test.stderr b/tests/ui-fulldeps/fluent-messages/test.stderr
index 0b3bb14ce51..978ac46c5a2 100644
--- a/tests/ui-fulldeps/fluent-messages/test.stderr
+++ b/tests/ui-fulldeps/fluent-messages/test.stderr
@@ -1,3 +1,8 @@
+warning[E0602]: unknown lint: `linker_messages`
+ |
+ = note: requested on the command line with `-A linker_messages`
+ = note: `#[warn(unknown_lints)]` on by default
```
Update books
## rust-lang/book
1 commits in e2fa4316c5a7c0d2499c5d6b799adcfad6ef7a45..d4d2c18cbd20876b2130a546e790446a8444cb32
2025-02-12 16:22:54 UTC to 2025-02-12 16:22:54 UTC
- Fix example for `cargo fix` (rust-lang/book#4226)
## rust-lang/reference
3 commits in de2d5289e45506b11dd652bef4f99de64be70e1c..6195dbd70fc6f0980c314b4d23875ac570d8253a
2025-02-12 15:40:30 UTC to 2025-02-11 20:35:17 UTC
- Revert "Update function-pointer.md for stabilization of `extended_varargs_abi_support`" (rust-lang/reference#1734)
- Rework error handling in mdbook-spec (rust-lang/reference#1733)
- `as` cast improvements (rust-lang/reference#1732)
Correctly escape hashtags when running `invalid_rust_codeblocks` lint
Fixes#136899.
We forgot to use `map_line` when we wrote this lint.
r? ``@notriddle``
Mark condition/carry bit as clobbered in C-SKY inline assembly
C-SKY's compare and some arithmetic/logical instructions modify condition/carry bit (C) in PSR, but there is currently no way to mark it as clobbered in `asm!`.
This PR marks it as clobbered except when [`options(preserves_flags)`](https://doc.rust-lang.org/reference/inline-assembly.html#r-asm.options.supported-options.preserves_flags) is used.
Refs:
- Section 1.3 "Programming model" and Section 1.3.5 "Condition/carry bit" in CSKY Architecture user_guide:
9f7121f7d4/CSKY%20Architecture%20user_guide.pdf
> Under user mode, condition/carry bit (C) is located in the lowest bit of PSR, and it can be
accessed and changed by common user instructions. It is the only data bit that can be visited
under user mode in PSR.
> Condition or carry bit represents the result after one operation. Condition/carry bit can be
clearly set according to the results of compare instructions or unclearly set as some
high-precision arithmetic or logical instructions. In addition, special instructions such as
DEC[GT,LT,NE] and XTRB[0-3] will influence the value of condition/carry bit.
- Register definition in LLVM:
https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/CSKY/CSKYRegisterInfo.td#L88
cc ```@Dirreke``` ([target maintainer](aa6f5ab18e/src/doc/rustc/src/platform-support/csky-unknown-linux-gnuabiv2.md (target-maintainers)))
r? ```@Amanieu```
```@rustbot``` label +O-csky +A-inline-assembly
Rename rustc_middle::Ty::is_unsafe_ptr to is_raw_ptr
The wording unsafe pointer is less common and not mentioned in a lot of places, instead this is usually called a "raw pointer". For the sake of uniformity, we rename this method.
This came up during the review of
https://github.com/rust-lang/rust/pull/134424.
r? `@Noratrieb`
This continues two ongoing projects:
- Replacing ascii art with real icons that don't look like
syntax, are understandable to people who're familiar with
desktop computers and smart devices, and aren't ugly.
- Using labels and tooltips to clarify these icons, when the
limits of popular iconography hit us. In this case, I've added
tooltips, because, unfortunately, there's not room for
always-visible labels.
use cc archiver as default in `cc2ar`
We should remove entire `cc2ar` but `cc` doesn't seem to cover all the conditions that `cc2ar` handles. For now, I replaced the `else` logic only, which is a bit hacky and unstable.
Fixes#136759
Change swap_nonoverlapping from lang to library UB
The implementation of ptr::swap_nonoverlapping does not always escalate its safety contract to language UB, so it should be `check_library_ub`.
Fixes https://github.com/rust-lang/miri/issues/4188
dev-guide: Link to `t-lang` procedures for new features
I was confused in https://github.com/rust-lang/rust/pull/136867, because while I did remember that such a procedure existed, but I couldn't seem to find it in the dev guide.
Nuke `Buffer` abstraction from `librustdoc`, take 2 💣
In https://github.com/rust-lang/rust/pull/136656 I found out that the for_html field in the Buffer struct was never read, and pondered if Buffer had any utility at all. `@GuillaumeGomez` said he agrees that it can be just removed. So this PR is me removing it. So, r? `@aDotInTheVoid` , maybe?
Supersedes #136748
(S)ccache can be useful for more things that just LLVM. For example, we will soon want to use it also for GCC, and theoretically also for building stage0 Rust tools.
Rollup of 8 pull requests
Successful merges:
- #134981 ( Explain that in paths generics can't be set on both the enum and the variant)
- #136698 (Replace i686-unknown-redox target with i586-unknown-redox)
- #136767 (improve host/cross target checking)
- #136829 ([rustdoc] Move line numbers into the `<code>` directly)
- #136875 (Rustc dev guide subtree update)
- #136900 (compiler: replace `ExternAbi::name` calls with formatters)
- #136913 (Put kobzol back on review rotation)
- #136915 (documentation fix: `f16` and `f128` are not double-precision)
r? `@ghost`
`@rustbot` modify labels: rollup
[rustdoc] Move line numbers into the `<code>` directly
Fixes#84242.
This is the first for adding support for https://github.com/rust-lang/rust/issues/127334 and also for another feature I'm working on.
A side-effect of this change is that it also fixes source code pages display in lynx since they're not directly in the source code.
To allow having code wrapping, the grid approach doesn't work as the line numbers are in their own container, so we need to move them into the code. Now with this, it becomes much simpler to do what we want (with CSS mostly). One downside: the highlighting became more complex and slow as we need to generate some extra HTML tags directly into the highlighting process. However that also allows to not have a huge HTML size increase.
You can test the result [here](https://rustdoc.crud.net/imperio/move-line-numbers-into-code/scrape_examples/fn.test_many.html) and [here](https://rustdoc.crud.net/imperio/move-line-numbers-into-code/src/scrape_examples/lib.rs.html#10).
The appearance should have close to no changes.
r? ``@notriddle``
improve host/cross target checking
Using an invalid equality operator on `builder.config.build !=/==` can be hard to detect in reviews (which is quite dangerous). Replaced them with `is_host_target`, which is much clearer as it explicitly states what it does.