Make sure to rebuild rustdoc if `src/rustdoc-json-types` is changed
I think `rustdoc-json-types` was more recently split out, so this download-rustc logic became outdated as it wasn't tracked. This PR adds `src/rustdoc-json-types` to be tracked for difference versus upstream, so that we properly rebuild rustdoc if it has changes versus upstream.
Fixesrust-lang/rust#142738.
### Local testing
This is not so easy to test locally because it requires download-rustc. To test this, you need to:
1. Disable `download-rustc` inhibition from bootstrap changes versus upstream, by including `:!src/bootstrap` in 255aa22082/src/bootstrap/src/core/config/config.rs (L67-L74).
2. Then, use a config like `profile = "tools"` which by default uses `download-rustc = "if-unchanged"`.
3. Run `./x test tests/rustdoc-json` one time, to "prime" initial build caches.
4. Change the `FORMAT_VERSION` in `src/rustdoc-json-types`, i.e.
```diff
diff --git a/src/rustdoc-json-types/lib.rs b/src/rustdoc-json-types/lib.rs
index 1f93895ae07..72a3720c7b4 100644
--- a/src/rustdoc-json-types/lib.rs
+++ b/src/rustdoc-json-types/lib.rs
``@@`` -38,7 +38,7 ``@@``
// are deliberately not in a doc comment, because they need not be in public docs.)
//
// Latest feature: Pretty printing of inline attributes changed
-pub const FORMAT_VERSION: u32 = 48;
+pub const FORMAT_VERSION: u32 = 666;
```
5. Observe that without this patch, `rustdoc-json` tests fail because `FORMAT_VERSION` mismatch. Observe that with this patch, rustdoc gets properly rebuilt and `rustdoc-json` tests pass.
cc ``@aDotInTheVoid``
r? Kobzol
add issue template for rustdoc
~~This also expands the scope of the "diagnostic
issue" template to include rustdoc lints,
meaning diagnostic issues will need triaging again. I think this is preferable to the alternative of
cramming even more cases under a single issue template.~~
r? t-rustdoc
Use jemalloc for Clippy
The tool macros are annoying, we should IMO just get rid of them, create separate steps for each tool and (re)use some builders in them to share the build code.
r? `@ghost`
Use a distinct `ToString` implementation for `u128` and `i128`
Part of https://github.com/rust-lang/rust/issues/135543.
Follow-up of rust-lang/rust#136264.
When working on https://github.com/rust-lang/rust/pull/142098, I realized that `i128` and `u128` could also benefit from a distinct `ToString` implementation so here it.
The last commit is just me realizing that I forgot to add the format tests for `usize` and `isize`.
Here is the bench comparison:
| bench name | last nightly | with this PR | diff |
|-|-|-|-|
| bench_i128 | 29.25 ns/iter (+/- 0.66) | 17.52 ns/iter (+/- 0.7) | -40.1% |
| bench_u128 | 34.06 ns/iter (+/- 0.21) | 16.1 ns/iter (+/- 0.6) | -52.7% |
I used this code to test:
```rust
#![feature(test)]
extern crate test;
use test::{Bencher, black_box};
#[inline(always)]
fn convert_to_string<T: ToString>(n: T) -> String {
n.to_string()
}
macro_rules! decl_benches {
($($name:ident: $ty:ident,)+) => {
$(
#[bench]
fn $name(c: &mut Bencher) {
c.iter(|| convert_to_string(black_box({ let nb: $ty = 20; nb })));
}
)+
}
}
decl_benches! {
bench_u128: u128,
bench_i128: i128,
}
```
Handle win32 separator for cygwin paths
This PR handles a issue that cygwin actually supports Win32 path, so we need to handle the Win32 prefix and separaters.
r? `@mati865`
cc `@jeremyd2019`
~~Not sure if I should handle the prefix like the windows target... Cygwin *does* support win32 paths directly going through the APIs, but I think it's not the recommended way.~~
Here I just use `cygwin_conv_path` because it handles both cygwin and win32 paths correctly and convert them into absolute POSIX paths.
UPDATE: Windows path prefix is handled.
Enable automatic cross-compilation in run-make tests
Supersedes rust-lang/rust#138066.
Blocker for rust-lang/rust#141856.
Based on rust-lang/rust#138066 plus `rustdoc()` cross-compile changes.
### Summary
This PR automatically specifies `--target` to `rustc()` and `rustdoc()` to have `rustc`/`rustdoc` produce cross-compiled artifacts in run-make tests by default, unless:
- `//@ ignore-cross-compile` is used, or
- `bare_{rustc,rustdoc}` are used, or
- Explicit `.target()` is specified, which overrides the default cross-compile target.
Some tests are necessarily modified:
- Tests that have `.target(target())` have that incantation removed (since this is now automatically the default).
- Some tests have `//@ needs-target-std`, but are a necessary-but-insufficient condition, and are changed to `//@ ignore-cross-compile` instead as host-only tests.
- A few tests received `//@ ignore-musl` that fail against `x86_64-unknown-linux-musl` because of inability to find `-lunwind`. AFAICT, they don't *need* to test cross-compiled artifacts.
- Some tests are constrained to host-only for now, because the effort to make them pass on cross-compile does not seem worth the complexity, and it's not really *meaningfully* improving test coverage.
try-job: dist-various-1
{aarch64,x86_64}-pc-windows-gnullvm: build host tools
This is a temporary single-release workflow to create stage0 for these targets.
I opted for bootstrapping from Linux because that's the easiest host system to work with, but once this hits beta, having dedicated Windows runners would be sensible and probably preferable.
`--enable-full-tools` for whatever reason doesn't seem to work when cross-compiling, because LLVM tools for the new hosts are not copied into the expected directory.
https://github.com/rust-lang/compiler-team/issues/877
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#135656 (Add `-Z hint-mostly-unused` to tell rustc that most of a crate will go unused)
- rust-lang/rust#138237 (Get rid of `EscapeDebugInner`.)
- rust-lang/rust#141614 (lint direct use of rustc_type_ir )
- rust-lang/rust#142123 (Implement initial support for timing sections (`--json=timings`))
- rust-lang/rust#142377 (Try unremapping compiler sources)
- rust-lang/rust#142674 (remove duplicate crash test)
r? `@ghost`
`@rustbot` modify labels: rollup
remove duplicate crash test
I noticed near duplication between "library/alloctests/tests/testing/crash_test.rs" and "library/alloctests/testing/crash_test.rs" and wanted to try and remove that. The only difference is the path used to import `Debug`, but it seems not to matter. Perhaps my change is still wrong?
r? ```@bjorn3```
Add `-Z hint-mostly-unused` to tell rustc that most of a crate will go unused
This hint allows the compiler to optimize its operation based on this assumption, in order to compile faster. This is a hint, and does not guarantee any particular behavior.
This option can substantially speed up compilation if applied to a large dependency where the majority of the dependency does not get used. This flag may slow down compilation in other cases.
Currently, this option makes the compiler defer as much code generation as possible from functions in the crate, until later crates invoke those functions. Functions that never get invoked will never have code generated for them. For instance, if a crate provides thousands of functions, but only a few of them will get called, this flag will result in the compiler only doing code generation for the called functions. (This uses the same mechanisms as cross-crate inlining of functions.) This does not affect `extern` functions, or functions marked as `#[inline(never)]`.
This option has already existed in nightly as `-Zcross-crate-inline-threshold=always` for some time, and has gotten testing in that form. However, this option is still unstable, to give an opportunity for wider testing in this form.
Some performance numbers, based on a crate with many dependencies having just *one* large dependency set to `-Z hint-mostly-unused` (using Cargo's `profile-rustflags` option):
A release build went from 4m07s to 2m04s.
A non-release build went from 2m26s to 1m28s.
remove duplicate crash test
I noticed near duplication between "library/alloctests/tests/testing/crash_test.rs" and "library/alloctests/testing/crash_test.rs" and wanted to try and remove that. The only difference is the path used to import `Debug`, but it seems not to matter. Perhaps my change is still wrong?
r? ``@bjorn3``
Clarify bootstrap tools description
The existence of `stage0-bootstrap-tools` suggests the possiblity of `stage1/N-bootstrap-tools`, but that's not really a thing. Also it doesn't fit the new bootstrap model, where `stageN` essentially means that it was built with a `stageN-1` compiler (except for std).
r? ``@jieyouxu``
CodeGen: rework Aggregate implemention for rvalue_creates_operand cases
A non-trivial refactor pulled out from rust-lang/rust#138759
r? workingjubilee
The previous implementation I'd written here based on `index_by_increasing_offset` is complicated to follow and difficult to extend to non-structs.
This changes the implementation, without actually changing any codegen (thus no test changes either), to be more like the existing `extract_field` (<2b0274c71d/compiler/rustc_codegen_ssa/src/mir/operand.rs (L345-L425)>) in that it allows setting a particular field directly.
Notably I've found this one much easier to get right, in particular because having the `OperandRef<Result<V, Scalar>>` gives a really useful thing to include in ICE messages if something did happen to go wrong.
Affirm `-Cforce-frame-pointers=off` does not override
This PR exists to document that we (that is, the compiler reviewer) implicitly made a decision in rust-lang/rust#86652 that defies the expectations of some programmers. Some programmers believe `-Cforce-frame-pointers=false` should obey the programmer in all cases, forcing the compiler to avoid generating frame pointers, even if the target specification would indicate they must be generated. However, many targets rely on frame pointers for fast or sound unwinding.
T-compiler had a weekly triage meeting on 2025-05-22. This topic was put to discussion because some programmers may expect the target-overriding behavior. In that meeting we decided removing frame pointers, at least with regards to the contract of the `-Cforce-frame-pointers` option, is not required, even if `=off` is passed, and that we will not do so if the target would expect them. This follows from the documentation here: https://doc.rust-lang.org/rustc/codegen-options/index.html#force-frame-pointers
We may separately pursue trying to clarify the situation more emphatically in our documentation, or warn when people pass the option when it doesn't do anything.
Safer implementation of RepeatN
I've seen the "Use MaybeUninit for RepeatN" commit while reading This Week In Rust and immediately thought about something I've written some time ago - https://github.com/Soveu/repeat_finite/blob/master/src/lib.rs.
Using the fact, that `Option` will find niche in `(T, NonZeroUsize)`, we can construct something that has the same size as `(T, usize)` while completely getting rid of `MaybeUninit`.
This leaves only `unsafe` on `TrustedLen`, which is pretty neat.
use `MixedBitSet` for borrows-in-scope dataflow analysis
The `Borrows` dataflow analysis uses a dense bitset, but a bitset supporting _some_ amount of sparseness is better suited for big functions with a big number of loans.
The cutoff between dense and chunked bitset is around 2K loans IIRC, and we could finesse that value if we wanted to, but as-is it happens to a couple of rustc-perf benchmarks (which IIRC are at least partially generated from macros and the likes.). It's a small win on these two, and shouldn't have any impact on the others.
r? `@matthewjasper`
Jakub Beránek
bors
Tshepang Mbambo
The rustc-dev-guide Cronjob Bot
Manuel Drehwald
Urgau
Boxy
nora
lolbinarycat
Chris Bloodsworth
Alice Ryhl
Urgau