rustdoc: quality of life changes
- Support `=` shortcut (alongside `+`) to expand all sections. Already support `s` and `S`, `Shift` or not.
- ~~Fix search-input's placeholder. The input is auto focused, any key press will be accepted as input not shortcut, current placeholder is missleading.~~
bootstrap: Add snapshot tests for path-to-step handling
This PR adds a suite of snapshot tests for how bootstrap translates command-line “paths” (which are not necessarily actual paths) into a set of top-level steps to execute.
Unlike the existing suite of snapshot tests (for transitive step logging), I decided to use `.snap` files over inline snapshots, because I find that inline snapshots quickly make test files impossible to navigate. Instead, I set up a macro that makes it relatively easy to add or modify test cases.
Using `.snap` files also means that the tests can be blessed by setting `INSTA_UPDATE=always`, without necessarily needing the `cargo insta` tool installed, though the tool can still be used instead if desired.
These snapshot tests capture _current_ behavior, to prevent unintended changes or regressions. If the current behavior is wrong or undersirable, then any fix will necessarily have to re-bless the affected tests!
r? Kobzol
fix(rustdoc): Color doctest errors
`@fmease's` [Deep analysis](https://github.com/rust-lang/rust/issues/148749#issuecomment-3508455278) on the problem
> Yeah, here's a deep analysis by me from a few weeks back of what's going on ([#148101 (comment)](https://github.com/rust-lang/rust/pull/148101#discussion_r2462756875)):
>
> > […]
> > However, since said PR ([#147207](https://github.com/rust-lang/rust/pull/147207): migrating coloring crates), `HumanEmitter::supports_color()` unconditionally(!) returns `false` (in fact, `Emitter::supports_color` is no longer used by anyone else and should be removed), so there's no reason to keep it. Rephrased, since that PR all compiler diagnostics for doctests are uncolored.
> > You could argue that I should keep it and patch `supports_color` in rustc to "work again". However, I'd rather rework our doctest coloring wholesale in a separate PR. At least before that migration PR, our setup was quite busted:
> >
> > 1. First of all, it didn't query+set `supports_color` for syntactically invalid doctests, so syntax errors were always shown without color (contrary to e.g., name resolution errors).
> > 2. Second of all, calling `supports_color()` here was quite frankly wrong: Piping the output of `rustdoc … --test` into a file (or `| cat` or whatever) did **not** suppress colors. I'm not actually sure if we can ever address that nicely (without stripping ANSI codes after the fact) since we pass that diagnostic to `libtest`, right? I might very well be wrong here, maybe it's a non-issue.
<hr>
```rust
/// ```
/// foo
/// ```
fn foo() {}
```
```
rustdoc --test lib.rs
```
Stable:
<img width="377" height="290" alt="stable" src="https://github.com/user-attachments/assets/cd20f947-b58d-42db-8735-797613baa9cc" />
Beta:
<img width="377" height="290" alt="beta" src="https://github.com/user-attachments/assets/f02588fd-41d2-4642-b03a-5554a68671eb" />
Nightly:
<img width="377" height="290" alt="nightly" src="https://github.com/user-attachments/assets/871cb417-f47e-4058-8a76-3bcd538ce141" />
After:
<img width="377" height="290" alt="after" src="https://github.com/user-attachments/assets/5734c01f-3f1c-44bb-9404-628c0c33b440" />
Note: This will need to be backported to `beta`
Fixes: rust-lang/rust#148749
rustc_target: introduce Abi, Env, Os
Improve type safety by using an enum rather than strings.
I'm not really sure this is better since only a few vendors have special semantics. r? ``@nnethercote``
[rustdoc] Fix invalid jump to def macro link generation
Follow-up of https://github.com/rust-lang/rust/issues/147820.
I realized that when there was no intra-doc link linking to the same item, then the generated link for macros in jump to def would be invalid.
To make the code less redundant, I merged the "registering" of items and the href generation use the same code for macros.
r? `````@notriddle`````
Prepare for additional enums like Vendor and Os which have true
`Unknown` variants. We want to use the same name for the escape hatch
for all of these, thus rename this one.
[rustdoc] Remove unneeded `allow(rustc::potential_query_instability)`
Originally replaced it with an `expect` and since it failed compilation because it wasn't triggered, I removed it.
std: support `RwLock` and thread parking on TEEOS
Since TEEOS supports pthread mutexes and condvars, it can share the pthread-based thread parking implementation and thus also the queue-based `RwLock` implementation used on other platforms.
CC ``@petrochenkov`` ``@Sword-Destiny``
bootstrap: respect `build.python` on macOS
The `python()` method was hardcoded to return `/usr/bin/python3` on macOS, ignoring the `build.python` config option. This change respects the config while maintaining the system Python as the default.
compiletest: Migrate `TestProps` directive handling to a system of named handlers
One of the very silly things about directive processing in compiletest is that for each directive in the test file, we proceed to check it against dozens of different directive names in linear sequence, without any kind of indexed lookup, and without any early-exit after a known directive name is found (unless a panic occurs).
This PR is a big step away from that, by taking the `iter_directives` loop in `TestProps::load_from` and making all of its directive processing dispatch to a hashtable of individual name-specific handlers instead.
---
The handler system is set up in a way that should allow us to add capabilities or change the implementation as needed, without having to mass-modify the existing handlers (e.g. this is why the `handler` and `multi_handler` functions are used).
---
This PR is focused on mass-migrating all of the `TestProps` directive processing into handlers. Most of the resulting handlers could obviously be simplified further (e.g. by avoiding the redundant name checks that were needed in the pre-migration code), but I've avoided doing any such simplifications in this PR to keep its scope limited and make reviewing easier.
The patches in this PR have been arranged so that the main migration can be inspected with `git diff --color-moved --color-moved-ws=ignore-all-space` to verify that it moves all of the relevant lines intact, without modifying or discarding any of them.
r? jieyouxu
rustdoc-json: move `target` to `json::conversions`
It belongs here, because it moves from a `rustc_*` type to a `rustdoc_json_types` type.
r? ```````@GuillaumeGomez```````
rustdoc: Erase `#![doc(document_private_items)]`
I just found out about the existence of `#![doc(document_private_items)]`. Apparently it was added by PR rust-lang/rust#50669 back in 2018 without any tests or docs as a replacement for some specific forms of the removed `#![doc(passes)]` / `#![doc(no_default_passes)]`.
However, rustc and rustdoc actually emit the deny-by-default lint `invalid_doc_attributes` for it (but if you allow it, the attribute does function)! To be more precise since PR rust-lang/rust#82708 (1.52, May 2021) which introduced lint `invalid_doc_attributes`, rust{,do}c has emitted a future-incompat warning for this attribute. And since PR rust-lang/rust#111505 (1.78, May 2024) that lint is deny by default. I presume nobody knew this attribute existed and thus it was never allowlisted.
Given the fact that since 2021 nobody has ever opened a ticket ([via](https://github.com/rust-lang/rust/issues?q=is%3Aissue+document_private_items)) complaining about the lint emission and the fact that GitHub code search doesn't yield any actual uses ([via](https://github.com/search?q=%2F%23%21%5C%5Bdoc%5C%28.*%3Fdocument_private_items%2F+language%3ARust&type=code&ref=advsearch)), I'm led to believe that nobody knows about and uses this attribute.
I don't find the existence of this attribute to be justified since in my view the flag `--document-private-items` is strictly superior: In most if not all cases, you don't want to "couple" your crate with this "mode" even if you gate it behind a cfg; instead, you most likely want to set this manually at invocation time, via a build config file like `.cargo/config.toml` or via a command runner like `just` I'd say.
Because of this I propose to wipe this attribute from existence. I don't believe it's worth cratering this (i.e., temporarily emitting a hard error for this attribute and running crater) given the fact that it's been undocumented since forever and led to a warning for years.
Add new `function_casts_as_integer` lint
The `function_casts_as_integer` lint detects cases where users cast a function pointer into an integer.
*warn-by-default*
### Example
```rust
fn foo() {}
let x = foo as usize;
```
```
warning: casting a function into an integer implicitly
--> $DIR/function_casts_as_integer.rs:9:17
|
LL | let x = foo as usize;
| ^^^^^^^^
|
help: add `fn() as usize`
|
LL | let x = foo as fn() as usize;
| +++++++
```
### Explanation
You should never cast a function directly into an integer but go through a cast as `fn` first to make it obvious what's going on. It also allows to prevent confusion with (associated) constants.
Related to https://github.com/rust-lang/rust/issues/81686 and https://stackoverflow.com/questions/68701177/whats-the-meaning-of-casting-a-rust-enum-variant-to-a-numeric-data-type
r? ````@urgau````
bors