By moving `RenderOptions` out of `Option`, because the two structs' uses
are almost entirely separate.
The only complication is that `unstable_features` is needed in both
structs, but it's a tiny `Copy` type so its duplication seems fine.
It turns out `markdown::render` is more complex than it first appears,
because it can invoke `doctest::make_test`, which requires session
globals and a thread pool.
So this commit changes it to use `interface::run_compiler`. Three of the
four paths in `main_args` now use `interface::run_compiler`.
rustc's startup has several layers, including:
- `interface::run_compiler` passes a closure, `f`, to
`run_in_thread_pool_with_globals`, which creates a thread pool, sets
up session globals, and passes `f` to `create_compiler_and_run`.
- `create_compiler_and_run` creates a `Session`, a `Compiler`, sets the
source map, and calls `f`.
rustdoc is a bit different.
- `main_args` calls `main_options` via
`run_in_thread_pool_with_globals`, which (again) creates a thread pool
(hardcoded to a single thread!) and sets up session globals.
- `main_options` has four different paths.
- The second one calls `interface::run_compiler`, which redoes the
`run_in_thread_pool_with_globals`! This is bad.
- The fourth one calls `interface::create_compiler_and_run`, which is
reasonable.
- The first and third ones don't do anything of note involving the
above functions, except for some symbol interning which requires
session globals.
In other words, rustdoc calls into `rustc_interface` at three different
levels. It's a bit confused, and feels like code where functionality has
been added by different people at different times without fully
understanding how the globally accessible stuff is set up.
This commit tidies things up. It removes the
`run_in_thread_pool_with_globals` call in `main_args`, and adjust the
four paths in `main_options` as follows.
- `markdown::test` calls `test::test_main`, which provides its own
parallelism and so doesn't need a thread pool. It had one small use of
symbol interning, which required session globals, but the commit
removes this.
- `doctest::run` already calls `interface::run_compiler`, so it doesn't
need further adjustment.
- `markdown::render` is simple but needs session globals for interning
(which can't easily be removed), so it's now wrapped in
`create_session_globals_then`.
- The fourth path now uses `interface::run_compiler`, which is
equivalent to the old `run_in_thread_pool_with_globals` +
`create_compiler_and_run` pairing.
* Since it's used exclusively on source pages, no need to explicitly
select.
* No need to hide it when the sidebar is open, since it fills the whole
page.
Rollup of 5 pull requests
Successful merges:
- #103087 (Documentation BTreeMap::append's behavior for already existing keys)
- #103089 (Mark derived StructuralEq as automatically derived.)
- #103102 (Clarify the possible return values of `len_utf16`)
- #103109 (PhantomData: inline a macro that is used only once)
- #103120 (rustdoc: Do not expect `doc(primitive)` modules to always exist)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
rustdoc: remove unused CSS `.search-container > *`
The two items it was really intended to target were the buttons, and those both need to have the style set directly on them anyway because the buttons are both child elements of wrappers.
6b3ede3f7b/src/librustdoc/html/static/css/rustdoc.css (L1406-L1411)
More dupe word typos
I only picked those changes (from the regex search) that I am pretty certain doesn't change meaning and is just a typo fix. Do correct me if any fix is undesirable and I can revert those. Thanks.
Migrate css highlight without change
This is a "previous" version of https://github.com/rust-lang/rust/pull/102663: only migrating to CSS variables, no changes. It's a bit more verbose because rules are not coherent between themes.
r? ``@notriddle``
rustdoc: don't ICE on `TyKind::Typeof`
Fixes#102986
I'm not sure why rustdoc started seeing `TyKind::Typeof` all of a sudden (the code being editted was last touched 3 months ago), probably something to do with error recovery? idk.
The two items it was really intended to target were the buttons, and those
both need to have the style set directly on them anyway because the buttons
are both child elements of wrappers.
rustdoc: merge separate `.item-info` CSS
Rough timeline:
* The longer `.content .item-info` selector originated in 110e7270ab. No reason seems to be given in the PR why it needed the `.content` part, but it was probably added because of <110e7270ab/src/librustdoc/html/static/rustdoc.css (L476-L478)>. That selector with the margin-bottom was removed when CSS containment was added in 8846c0853d.
* `.stability` was renamed `.item-info` in caf6c5790a.
* The selector without the `.content` was added in d48a39a5e2.
Rough timeline:
* The longer `.content .item-info` selector originated in
110e7270ab. No reason seems to be given in
the PR why it needed the `.content` part, but it was probably added because
of <110e7270ab/src/librustdoc/html/static/rustdoc.css (L476-L478)>.
That selector with the margin-bottom was removed when CSS containment
was added in 8846c0853d.
* `.stability` was renamed `.item-info` in
caf6c5790a.
* The selector without the `.content` was added in
d48a39a5e2.
translation: eager translation
Part of #100717. See [Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/336883-i18n/topic/.23100717.20lists!/near/295010720) for additional context.
- **Store diagnostic arguments in a `HashMap`**: Eager translation will enable subdiagnostics to be translated multiple times with different arguments - this requires the ability to replace the value of one argument with a new value, which is better suited to a `HashMap` than the previous storage, a `Vec`.
- **Add `AddToDiagnostic::add_to_diagnostic_with`**: `AddToDiagnostic::add_to_diagnostic_with` is similar to the previous `AddToDiagnostic::add_to_diagnostic` but takes a function that can be used by the caller to modify diagnostic messages originating from the subdiagnostic (such as performing translation eagerly). `add_to_diagnostic` now just calls `add_to_diagnostic_with` with an empty closure.
- **Add `DiagnosticMessage::Eager`**: Add variant of `DiagnosticMessage` for eagerly translated messages
(messages in the target language which don't need translated by the emitter during emission). Also adds `eager_subdiagnostic` function which is intended to be invoked by the diagnostic derive for subdiagnostic fields which are marked as needing eager translation.
- **Support `#[subdiagnostic(eager)]`**: Add support for `eager` argument to the `subdiagnostic` attribute which generates a call to `eager_subdiagnostic`.
- **Finish migrating `rustc_query_system`**: Using eager translation, migrate the remaining repeated cycle stack diagnostic.
- **Split formatting initialization and use in diagnostic derives**: Diagnostic derives have previously had to take special care when ordering the generated code so that fields were not used after a move.
This is unlikely for most fields because a field is either annotated with a subdiagnostic attribute and is thus likely a `Span` and copiable, or is a argument, in which case it is only used once by `set_arg`
anyway.
However, format strings for code in suggestions can result in fields being used after being moved if not ordered carefully. As a result, the derive currently puts `set_arg` calls last (just before emission), such as:
let diag = { /* create diagnostic */ };
diag.span_suggestion_with_style(
span,
fluent::crate::slug,
format!("{}", __binding_0),
Applicability::Unknown,
SuggestionStyle::ShowAlways
);
/* + other subdiagnostic additions */
diag.set_arg("foo", __binding_0);
/* + other `set_arg` calls */
diag.emit();
For eager translation, this doesn't work, as the message being translated eagerly can assume that all arguments are available - so arguments _must_ be set first.
Format strings for suggestion code are now separated into two parts - an initialization line that performs the formatting into a variable, and a usage in the subdiagnostic addition.
By separating these parts, the initialization can happen before arguments are set, preserving the desired order so that code compiles, while still enabling arguments to be set before subdiagnostics are added.
let diag = { /* create diagnostic */ };
let __code_0 = format!("{}", __binding_0);
/* + other formatting */
diag.set_arg("foo", __binding_0);
/* + other `set_arg` calls */
diag.span_suggestion_with_style(
span,
fluent::crate::slug,
__code_0,
Applicability::Unknown,
SuggestionStyle::ShowAlways
);
/* + other subdiagnostic additions */
diag.emit();
- **Remove field ordering logic in diagnostic derive:** Following the approach taken in earlier commits to separate formatting initialization from use in the subdiagnostic derive, simplify the diagnostic derive by removing the field-ordering logic that previously solved this problem.
r? ```@compiler-errors```
Since 98f05a0282 and
b5963f07e6 removed color classes from sidebar
items, there's no need for the selectors to be so specific any more.
This commit does have to change `h1.fqn a` to just be `h1 a`, so that the
header link color selector is less specific than the typed link at the end.
Since #89506 made docblocks start at `h2`, the main page link header should
be the only h1 in the page now.
