All HIR attributes are outer
Fixes https://github.com/rust-lang/rust/issues/142649. Closes https://github.com/rust-lang/rust/pull/142759.
All HIR attributes, including parsed and not yet parsed, will now be rendered as outer attributes by `rustc_hir_pretty`. The original style of the corresponding AST attribute(s) is not relevant for pretty printing, only for diagnostics.
r? ````@jdonszelmann````
rustdoc_json: conversion cleanups
A bunch of clean-to-types conversion cleanups I found while working on perf-related stuff in rustdoc_json.
r? ```@aDotInTheVoid```
Pass -Cpanic=abort for the panic_abort crate
The panic_abort crate must be compiled with panic=abort, but cargo doesn't allow setting the panic strategy for a single crate the usual way using `panic="abort"`, but luckily per-package rustflags do allow this. Bootstrap previously handled this in its rustc wrapper, but for example the build systems of cg_clif and cg_gcc don't use the rustc wrapper, so they would either need to add one, patch the standard library or be unable to build a sysroot suitable for both panic=abort and panic=unwind (as is currently the case).
Required for https://github.com/rust-lang/rustc_codegen_cranelift/issues/1567
forward the bootstrap `runner` to `run-make`
The runner was already forwarded to `compiletest`, this just passes it on to `run-make` and uses it in the `run` functions.
The configuration can look like this
```toml
# in bootstrap.toml
[target.s390x-unknown-linux-gnu]
runner = "qemu-s390x -L /usr/s390x-linux-gnu"
```
Any C compilation automatically sets the correct target. Calls to rustc must use `.target(target())`. Then, a command like below will work by cross-compiling to the given target, and using the given runner for that target to execute the binary:
```
./x test tests/run-make/c-link-to-rust-va-list-fn --target s390x-unknown-linux-gnu
```
The runner can also be used for e.g. running with `valgrind`.
This PR also enables its use in the test case that I care about, hopefully that actually does work on the platforms that CI uses. We should probably run some try jobs to be sure?
r? `@jieyouxu`
try-job: test-various
try-job: armhf-gnu
Avoid a few more allocations in `write_shared.rs`
Inspired by rust-lang/rust#141421 , avoids a few `Vec`, `PathBuf` and `String` allocations in `write_shared.rs`. I don't think these will show up on benchmarks, but are still worthwhile IMHO.
Also includes a few small cleanups.
r? nnethercote - if you'd like :)
- `convert_static` -> `from_clean_static`
- `from_function` -> `from_clean_function`
To match the pre-existing `from_clean_item` and `FromClean::from_clean`.
I left `JsonRenderer::convert_item` unchanged because it's a bit
different.
The `FromClean` trait is used a lot for converting to rustdoc-json
format. But it's not used universally; there are still some ad hoc
functions and methods for converting. This commit fixes this
inconsistency by using `FromClean` more.
The commit also introduces `FromClean` for `Box` and `Option`. This lets
a lot of `as_ref` and `map` calls be removed in favour of simple
`into_json` calls.
We currently have both `FromClean<clean::Constant> for Constant` and
`FromClean<clean::ConstantKind> for Constant` which are basically
identical, but the former is unused.
Rename `LayoutS` to `LayoutData` in comments
`LayoutS` was renamed to `LayoutData`, but some comments in the compiler were not changed. This updates comments in the compiler (and one section of commented-out code in rust-analyzer) to refer to `LayoutData` instead of `LayoutS`.
cc <https://github.com/rust-lang/rust/pull/132252>, `@workingjubilee`
Add diagnostic items for Clippy
Clippy still uses some paths to access items from the standard library. Adding the missing diagnostic items allows removing the last remaining paths.
Closesrust-lang/rust-clippy#5393
rustdoc_json: improve handling of generic args
This PR fixes some inconsistencies and inefficiencies in how generic args are handled by rustdoc-json-types.
r? `@aDotInTheVoid`
They show up in three places: once as `Option<Box<GenericArgs>>`, once
as `Box<GenericArgs>`, and once as `GenericArgs`. The first option is
best. It is more compact because generic args are often missing. This
commit changes the latter two to the former.
Example output, before and after, for the `AssocItemConstraint` change:
```
{"name":"Offset","args":{"angle_bracketed":{"args":[],"constraints":[]}},"binding":{...}}
{"name":"Offset","args":null,"binding":{...}}
```
Example output, before and after, for the `Type::QualifiedPath` change:
```
{"qualified_path":{"name":"Offset","args":{"angle_bracketed":{"args":[],"constraints":[]}}, ...}}
{"qualified_path":{"name":"Offset","args":null, ...}}
```
This reduces JSON output size, but not by much (e.g. 0.5%), because
`AssocItemConstraint` and `Type::QualifiedPath` are uncommon.
A path without generic args, like `Reader`, currently has JSON produced
like this:
```
{"path":"Reader","id":286,"args":{"angle_bracketed":{"args":[],"constraints":[]}}}
```
Even though `types::Path::args` is `Option` and allows for "no args",
instead it gets represented as "empty args". (More like `Reader<>` than
`Reader`.)
This is due to a problem in `clean::Path::from_clean`. It only produces
`None` if the path is an empty string. This commit changes it to also
produce `None` if there are no generic args. The example above becomes:
```
{"path":"Reader","id":286,"args":null}
```
I looked at a few examples and saw this reduce the size of the JSON
output by 3-9%.
The commit also adds an assertion that non-final segments don't have any
generics; something the old code was implicitly relying on.
Note: the original sin here is that `clean::PathSegment::args` is not an
`Option`, unlike `{ast,hir}::PathSegment::args`. I want to fix that, but
it can be done separately.
Add CI check to ensure that rustdoc JSON `FORMAT_VERSION` is correctly updated
Follow-up of https://github.com/rust-lang/rust/pull/142601.
Tested it locally with: `BASE_COMMIT=1bb335244c311a07cee165c28c553c869e6f64a9 src/ci/docker/host-x86_64/mingw-check-1/validate-rustdoc-json-format-version-update.sh` (where `BASE_COMMIT` value was the commit before I made a wrong change with the `FORMAT_VERSION` update).
This is a first version. I plan to send a follow-up to also ensure that `FORMAT_VERSION` is updated if any code change is done in `rustdoc-json-types`. For that I just need to check that a line not starting with `/` and not an empty line was updated. Fun times with `grep` ahead. :')
cc `@aDotInTheVoid`
r? `@nnethercote`
Bringing `rustc_rayon_core` in tree as `rustc_thread_pool`
This PR moves [`rustc_rayon_core`](5fadf44/rayon-core) from commit `5fadf44` as suggested in [this zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/187679-t-compiler.2Fparallel-rustc/topic/Bringing.20.60rustc_rayon_core.60.20in.20tree). I tried to split the work into separate commits so it is easy to review. The first commit is a simple copy and paste from the fork, and subsequent changes were made to use the new crate and to ensure the new crate complies with different format and lint expectations.
**Call-out:** I was also wondering if I need to make any further changes to accommodate licensing requirements.
r? oli-obk
Convert `ilog(10)` to `ilog10()`
Except in tests, convert `integer.ilog(10)` to `integer.ilog10()` for better speed and to provide better examples of code that efficiently counts decimal digits. I couldn't find any instances of `integer.ilog(2)`.
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
De-dup common code from `ExternalCrate` methods
Also, return an `impl Iterator` instead of collecting into a `Vec`. Not sure if that'll have a measurable perf impact, but I think this PR still cleans up the two methods it touches quite nicely.
(I'm having trouble finding a name for the common method I extracted, currently called `foobar`, would love suggestions!)
correct template for `#[align]` attribute
Tracking issue: https://github.com/rust-lang/rust/issues/82232
related: https://github.com/rust-lang/rust/pull/142507
I didn't fully understand what `template!` did, clearly. An empty `#[align]` attribute was still rejected later, but without this change it does get suggested in certain cases.
I've also updated some outdated references to `#[repr(align)]` on functions.
r? ``@jdonszelmann``
Add config builder for bootstrap tests
I started writing a bunch of snapshot tests for build/check steps, and quickly realized that the current interface for defining them won't be enough, so I created a simple builder, which can scale to pretty much any kind of configuration in the future.
Refactor Translator
My main motivation was to simplify the usage of `SilentEmitter` for users like rustfmt. A few refactoring opportunities arose along the way.
* Replace `Translate` trait with `Translator` struct
* Replace `Emitter: Translate` with `Emitter::translator`
* Split `SilentEmitter` into `FatalOnlyEmitter` and `SilentEmitter`
Fix random failure when JS code is executed when the whole file was not read yet
Very randomly (and rarely), when I arrived on a page with `?search=something` in the URL, I got this error:
Moving the `initSearch` function at the bottom to ensure everything has been loaded fixes the issue.
PS: Sorry for the noise. Pushed to the wrong branch and https://github.com/rust-lang/rust/pull/142496 closed. ><
The panic_abort crate must be compiled with panic=abort, but cargo
doesn't allow setting the panic strategy for a single crate the usual
way using panic="abort", but luckily per-package rustflags do allow
this. Bootstrap previously handled this in its rustc wrapper, but for
example the build systems of cg_clif and cg_gcc don't use the rustc
wrapper, so they would either need to add one, patch the standard
library or be unable to build a sysroot suitable for both panic=abort
and panic=unwind (as is currently the case).
Update books
## rust-lang/book
1 commits in 4433c9f0cad8460bee05ede040587f8a1fa3f1de..8a6d44e45b7b564eeb6bae30507e1fbac439d72d
2025-06-18 17:06:36 UTC to 2025-06-18 17:06:36 UTC
- Chapter 12 from tech review (rust-lang/book#4410)
## rust-lang/reference
6 commits in d4c66b346f4b72d29e70390a3fa3ea7d4e064db1..50fc1628f36563958399123829c73755fa7a8421
2025-06-19 02:02:39 UTC to 2025-06-17 21:18:46 UTC
- Document inferred const args (`feature(generic_arg_infer)`) (rust-lang/reference#1835)
- const_eval: we allow references to statics and promoteds (rust-lang/reference#1858)
- Fix missing rule on destructors (rust-lang/reference#1861)
- Fix inconsistent heading depth (rust-lang/reference#1860)
- Fix recursive root-accessible grammar check (rust-lang/reference#1852)
- Fix grammar links (rust-lang/reference#1851)
## rust-lang/rust-by-example
1 commits in 9baa9e863116cb9524a177d5a5c475baac18928a..05c7d8bae65f23a1837430c5a19be129d414f5ec
2025-06-18 13:15:17 UTC to 2025-06-18 13:15:17 UTC
- Revert "introduce new ````@media```` query to set a higher content width on ultra wide screens" (rust-lang/rust-by-example#1939)
Reduce uses of `hir_crate`.
I tried rebasing my old incremental-HIR branch. This is a by-product, which is required if we want to get rid of `hir_crate` entirely.
The second commit is a drive-by cleanup. It can be pulled into its own PR.
r? ````@oli-obk````
Extract some shared code from codegen backend target feature handling
There's a bunch of code duplication between the GCC and LLVM backends in target feature handling. This moves that into new shared helper functions in `rustc_codegen_ssa`.
The first two commits should be purely refactoring. I am fairly sure the LLVM-side behavior stays the same; if the GCC side deliberately diverges from this then I may have missed that. I did account for one divergence, which I do not know is deliberate or not: GCC does not seem to use the `-Ctarget-feature` flag to populate `cfg(target_feature)`. That seems odd, since the `-Ctarget-feature` flag is used to populate the return value of `global_gcc_features` which controls the target features actually used by GCC. ``@GuillaumeGomez`` ``@antoyo`` is there a reason `target_config` ignores `-Ctarget-feature` but `global_gcc_features` does not? The second commit also cleans up a bunch of unneeded complexity added in https://github.com/rust-lang/rust/pull/135927.
The third commit extracts some shared logic out of the functions that populate `cfg(target_feature)` and the backend target feature set, respectively. This one actually has some slight functional changes:
- Before, with `-Ctarget-feature=-feat`, if there is some other feature `x` that implies `feat` we would *not* add `-x` to the backend target feature set. Now, we do. This fixesrust-lang/rust#134792.
- The logic that removes `x` from `cfg(target_feature)` in this case also changed a bit, avoiding a large number of calls to the (uncached) `sess.target.implied_target_features` (if there were a large number of positive features listed before a negative feature) but instead constructing a full inverse implication map when encountering the first negative feature. Ideally this would be done with queries but the backend target feature logic runs before `tcx` so we can't use that...
- Previously, if feature "a" implied "b" and "b" was unstable, then using `-Ctarget-feature=+a` would also emit a warning about `b`. I had to remove this since when accounting for negative implications, this emits a ton of warnings in a bunch of existing tests... I assume this was unintentional anyway.
The fourth commit increases consistency of the GCC backend with the LLVM backend.
The last commit does some further cleanup:
- Get rid of RUSTC_SPECIAL_FEATURES. It was only needed for s390x "backchain", but since LLVM 19 that is always a regular target feature so we don't need this hack any more. The hack also has various unintended side-effects so we don't want to keep it. Fixes https://github.com/rust-lang/rust/issues/142412.
- Move RUSTC_SPECIFIC_FEATURES handling into the shared parse_rust_feature_flag helper so all consumers of `-Ctarget-feature` that only care about actual target features (and not "crt-static") have it. Previously, we actually set `cfg(target_feature = "crt-static")` twice: once in the backend target feature logic, and once specifically for that one feature. IIUC, some targets are meant to ignore `-Ctarget-feature=+crt-static`, it seems like before this PR that flag still incorrectly enabled `cfg(target_feature = "crt-static")` (but I didn't test this).
- Move fixed_x18 handling together with retpoline handling.
- Forbid setting fixed_x18 as a regular target feature, even unstably. It must be set via the `-Z` flag.
``@bjorn3`` I did not touch the cranelift backend here, since AFAIK it doesn't really support target features. But if you ever do, please use the new helpers. :)
Cc ``@workingjubilee``
rewrite `optimize` attribute to use new attribute parsing infrastructure
r? ```@oli-obk```
I'm afraid we'll get quite a few of these PRs in the future. If we get a lot of trivial changes I'll start merging multiple into one PR. They should be easy to review :)
Waiting on #138165 first
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`
