[style] rustfmt `match`es with comments in or-patterns
Using https://github.com/rust-lang/rustfmt/pull/6893, I reformatted the whole codebase. The result is that `match`es that *should have* been formatted under normal circumstances but are getting skipped now got their expected format. These match expressions were being entirely skipped because they contain or-patterns with comments in between patterns, causing rustfmt to bail out entirely. The or-patterns with comments themselves remain untouched, but now the match arm bodies and other patterns without comments do get formatted under that PR.
Because the fix in rustfmt isn't landed yet, I reworked some of the or-patterns with comments so that formatting doesn't regress. Tried doing this only in larger blocks that are more likely to regress in the meantime.
(Introduced and) removed a bunch of stray backticks \` likely left after an editor autoclosed the intended closing \`, resulting in <code>\`name\`\`</code> in comments.
rustdoc: properly support macros with multiple kinds
Since it seems like I can't reopen https://github.com/rust-lang/rust/pull/145458, opening this one. Although, it's the same PR minus the last new commit to handle a comment that was left unresolved in the original PR. All relevant details are still in the original PR though.
It's an alternative (and likely a take-over) of https://github.com/rust-lang/rust/pull/148005 since lang-team rejected the idea to add documentation on macro branches, making the multiple files approach less suitable.
This implements rust-lang/rust#145153 in rustdoc. This PR voluntarily doesn't touch anything related to intra-doc links, I'll send a follow-up if needed.
So now about the implementation itself: this is a weird case where a macro can be different things at once but still only gets one file generated. I saw two ways to implement this:
1. Handle `ItemKind::Macro` differently and iter through its `MacroKinds` values.
2. Add new placeholder variants in the `ItemKind` enum, which means that when we encounter them in rendering, we need to ignore them. It also makes the `ItemKind` enum bigger (and also needs more code to be handled). Another downside is that it needs to be handled in the JSON output.
Now there was an interesting improvement that came with this PR in the `html::render::print_item::item_module` function: I simplified its implementation and split the different parts in a `HashMap` where the key is the item type. So then, we can just iterate through the keys and open/close the section at each iteration instead of keeping an `Option<section>` around.
From RFCs:
* https://github.com/rust-lang/rust/pull/144579
* https://github.com/rust-lang/rust/pull/145208
derive:
<img width="442" height="327" alt="Screenshot From 2026-04-18 03-11-40" src="https://github.com/user-attachments/assets/f69587a0-8a2b-4080-bc8a-b63dd18f21c1" />
attr:
<img width="442" height="327" alt="Screenshot From 2026-04-18 03-11-31" src="https://github.com/user-attachments/assets/bf9b235a-9d2f-435c-a91e-167562df6b68" />
both:
<img width="442" height="327" alt="Screenshot From 2026-04-18 03-11-50" src="https://github.com/user-attachments/assets/b7e8b3c6-eb99-495b-bdf9-17ba8fb4da0d" />
r? @notriddle
CI is currently down because apt is unable to access the repo at
dilos.org. It is failing inside the fortanix install script which tries
to run apt-get with the error:
```
5.679 E: Failed to fetch https://apt.dilos.org/dilos/dists/dilos2/InRelease 403 Forbidden [IP: 116.202.240.188 443]
```
These lines in the Dockerfile were added when Solaris builds were merged
into dist-various-2 in https://github.com/rust-lang/rust/pull/45001.
However, Solaris builds were split off in
https://github.com/rust-lang/rust/pull/138699. In that PR, these lines
adding the dilos repository weren't removed.
AFAICT, these are no longer necessary.
Correctly handle associated items in rustdoc macro expansion
Fixesrust-lang/rust#156075.
The bug was simply that it didn't cover associated items.
r? @Urgau
Lint level cleanups
Some naming improvements, some type safety improvements, and some simplifications. Details in individual commits.
r? @GuillaumeGomez
feat(rustdoc): stabilize `--emit` flag
### [---> FCP <---](https://github.com/rust-lang/rust/pull/146220#issuecomment-3740447985)
## Stabilization Report: `rustdoc --emit`
**Feature:** `rustdoc --emit`
**Tracking issue:** rust-lang/rust#83784
**Stabilization PR:** rust-lang/rust#146220
### What we are stabilizing
This stabilizes the `rustdoc --emit` flag, which controls what types of output rustdoc produces. The flag accepts a comma-separated list of the following emit types:
- `html-static-files` --- Shared static files with content-hashed filenames for safe caching.
- `html-non-static-files` --- Per-crate documentation files with deterministic filenames.
- `dep-info[=<path>]` --- A Makefile-compatible `.d` file listing all source files loaded during documentation generation. Same as rustc's dep-info files.
When `--emit` is not specified, the default behavior is `--emit=html-static-files,html-non-static-files` (i.e., full HTML documentation output, no dep-info).
### What we are not stabilizing
* Interaction between other unstable options, such as `-Zrustdoc-mergeable-info` and `--output-format=doctest`
* Available options and the default options when `--emit` not specified.
* Extension of per-type emit paths for options currently missing that.
### Motivation
#### Cargo
The primary consumer is Cargo, which needs `--emit=dep-info=<path>` to precisely track the input dependencies of a rustdoc invocation (see the [`-Zrustdoc-depinfo`] unstable Cargo feature). Without dep-info, Cargo cannot detect changes to files pulled in via `#[path = "..."]` or similar mechanisms and leads to stale documentation in incremental builds.
Cargo also uses the selective emission mechanism (`html-static-files` / `html-non-static-files`) when the unstable [`-Zrustdoc-mergeable-info`] feature is active. It skips writing shared static files and search index during per-crate doc generation and defer them to a final merge phase.
Under stable usage, Cargo passes all three emit types together.
#### docs.rs
docs.rs is the other major consumer. It uses selective emission to avoid redundantly copying toolchain-wide static files for every crate, which has historically been a source of breakage. See the tracking rust-lang/rust#83784 and the about page for more <https://docs.rs/about/download>.
### Tests
- `tests/run-make/emit-shared-files` --- Verifies selective emission of static vs non-static files.
- `tests/run-make/rustdoc-dep-info` --- Verifies dep-info generation, including explicit path and `--out-dir` interaction.
- `tests/run-make/rustdoc-scrape-examples-dep-info` --- Verifies dep-info works with scrape-examples.
- `tests/run-make/rustdoc-default-output/` --- Verifies `--help` output shows `[html-static-files,html-non-static-files,dep-info]`
[`-Zrustdoc-depinfo`]: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#rustdoc-depinfo
[`-Zrustdoc-mergeable-info`]: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#rustdoc-mergeable-info
`LevelSpec` has two related fields, `level` and `lint_id`. This commit
makes the fields private (and introduces getters) to ensure they are set
together using only valid combinations.
The commit also introduces `is_allow` and `is_expect` methods because
those are useful.
These methods return `Option<(Self, Option<LintExpectationId>)>`. But
all the call sites except one don't look at the
`Option<LintExpectationId>`.
This commit simplifies these methods to not return the
`Option<LintExpectationId>`. This means they no longer need to be passed
a closure to compute an `AttrId` (which is usually discarded anyway).
The commit also renames `from_attr` as `from_opt_symbol`, because it
takes an `Option<Symbol>`, not an `Attribute`.
These changes simplify all the call sites that don't need the
`Option<LintExpectationId>`, and also the one call site that does (in
`LintLevelsBuilder::add`): that call site no longer needs to do an
awkward destructuring, and can instead build the appropriate
`LintExpectationId` directly.
compiletest: Rename `//@ ignore-pass` to `//@ no-pass-override`
By convention, compiletest directives starting with `ignore-*` normally cause the test itself to be skipped under certain conditions.
The `//@ ignore-pass` directive was the only exception to that convention. The new name should hopefully do a better job of communicating its effect, which is to cause the `--pass` flag to not override the test's `build-pass` or `run-pass` directive.
The `//@ no-pass-override` directive is mainly useful for tests that expect warnings produced during codegen.
---
r? jieyouxu
compiletest: Enforce that directives are consistently used with or without a colon
With the notable exception of `//@ pp-exact`, all directives expect to either always be used *with* a colon, or always be used *without* a colon. For example:
- `//@ uses-colon: value`
- `//@ no-colon` or `//@ no-colon (remark)`
Currently we just silently discard directives that use the wrong syntax, which is not great.
This PR therefore makes `parse_name_directive` and `parse_name_value_directive` panic if the wrong syntax is encountered.
The parser for `pp-exact` has been adjusted to check for the colon before deciding which parse method to call.
r? jieyouxu
It is misnamed, given that it has three fields: `level`, `lint_id`, and
`src`. (Presumably the `lint_id` was added later.)
This commit renames it as `LevelSpec`. (I also considered `LevelInfo`
but that's very generic. `Spec` has pre-existing uses in
`LintLevelsProvider::current_specs` and `LintSet::specs` and
`ShallowLintLevelMap::specs`.)
Related things renamed as well:
- `level` -> `level_spec` (where appropriate)
- `lint_levels` -> `lint_level_specs`
- `get_lint_level` -> `get_lint_level_spec`
- `level_and_source` -> `level_spec`
- `CodegenLintLevels` -> `CodegenLintLevelSpecs`
- `raw_lint_id_level` -> `raw_lint_level_spec`
- `lint_level_at_node` -> `lint_level_spec_at_node`
- `reveal_actual_level` -> `reveal_actual_level_spec`
- `probe_for_lint_level` -> `probe_for_lint_level_spec`
This clears up a lot of `Level` vs. `LevelSpec` ambiguity. E.g. no more
`level.level` expressions.
Clippy subtree update
r? Manishearth
`Cargo.lock` update due to patch version bump in `ui_test`.
One day early, as I won't have access to my laptop from tomorrow till Sunday
Split the node_id_to_def_id table into a per-owner table
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/138995)*
My goal is to split all the resolver tables that get passed to act lowering into per-owner tables, so that all information that ast lowering needs from the resolver is separated by owners. This should allow us to fully split ast lowering to have one query invocation per owner that steal the individual resolver results for each owner.
part of https://github.com/rust-lang/rust-project-goals/issues/620
bootstrap: remap windows-style OUT_DIR paths
### problem:
on windows, some paths embedded into debuginfo / metadata may internally use `\` separators, while the existing `RUSTC_DEBUGINFO_MAP` remapping only covers the `/` form of `self.build.out`.
### fix:
add an additional remap entry for the windows style `\` variant of `self.build.out`.
### result:
improves path remapping consistency on windows, in turn helping with reproducibility.
r? @bjorn3
By convention, compiletest directives starting with `ignore-*` normally cause
the test itself to be skipped under certain conditions.
The `//@ ignore-pass` directive was the only exception to that convention. The
new name should hopefully do a better job of communicating its effect, which is
to cause the `--pass` flag to not override the test's `build-pass` or
`run-pass` directive.
The `//@ no-pass-override` directive is mainly useful for tests that expect
warnings produced during codegen.
Don't unnecessarily try to obtain the type-dependent definition of callees
in `visit_expr`, just let `visit_qpath` handle callees.
This means that for callees that are
* `Resolved` paths (the majority of callees) we don't try to `typeck` the
enclosing body which should improve perf if the body doesn't contain
any type-dependent definitions.
* actually `TypeRelative` paths we don't resolve them twice (with
slightly different spans)
`rustc_resolve` doesn't resolve type-relative paths since that's the job
of HIR ty lowering and HIR typeck. `segment.res` comes from
`rustc_resolve` and is thus always `Res::Err`.
So just try to obtain the `TypeckResults` immediately since they contain
the actual resolution as deduced by HIR typeck.
enable more f16/f128 tests in Miri
See the individual commit messages for details.
The last commit is a drive-by comment fix that was not worth its own PR.
r? @tgross35
Add Enzyme to build-manifest and rustup
This PR adds the autodiff component (Enzyme) to build-manifest, and thus also to (nightly) Rustup.
It is marked as nightly-only and as -preview.
After this PR lands, unless I messed something up, starting with the following nightly, the following should work (on supported targets):
```bash
rustup +nightly component add enzyme
RUSTFLAGS="-Zautodiff=Enable" cargo +nightly build
```
CC @ZuseZ4
r? @Mark-Simulacrum
closes: https://github.com/rust-lang/rust/issues/145899
bors