rustdoc: stabilise --default-theme command line option
As discussed in #77213, this seems like it has bedded in and can be safely and usefully made stable.
(rustdoc already has other stable options that interact quite intimately with the rustdoc-supplied CSS, and also an option for supplying entirely different CSS, so exposing the theme names this way seems a very minor step.)
There is also a commit to do some minor grammar fixes to the help message.
Highlight edition-specific keywords correctly in code blocks, accounting for code block edition modifiers
Previously, edition-specific keywords (such as `async` and `await`) were not highlighted in code blocks, regardless of what edition was set. With this PR, this issue is fixed.
Now, the following behavior happens:
- When a code block is explicitly set to edition X, keywords from edition X are highlighted
- When a code block is explicitly set to a version that does not contain those keywords from edition X (e.g. edition Y), keywords from edition X are **not** highlighted
- When a code block has no explicit edition, keywords from the edition passed via `--edition` to rustdoc are highlighted
For example, a project set with `edition = "2015"` in its `Cargo.toml` would not highlight `async`/`await` unless the code block was set to `edition2018`. Additionally, a project set with `edition = "2018"` in its `Cargo.toml` *would* highlight `async`/`await` unless the code block was set to a version that did not contain those keywords (e.g. `edition2015`).
This PR fixes#80004.
r? `@jyn514`
Rename rustc_middle::lint::LintSource
Rename [`rustc_middle::lint::LintSource`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/enum.LintSource.html) to `rustc_middle::lint::LintLevelSource`.
This enum represents the source of a *lint level*, not a lint. This should improve code readability.
Update: Also documents `rustc_middle::lint::LevelSource` to clarify.
Remap instrument-coverage line numbers in doctests
This uses the `SourceMap::doctest_offset_line` method to re-map line
numbers from doctests. Remapping columns is not yet done, and rustdoc
still does not output the correct filename when running doctests in a
workspace.
Part of #79417 although I dont consider that fixed until both filenames
and columns are mapped correctly.
r? `@richkadel`
I might jump on zulip the comming days. Still need to figure out how to properly write tests for this, and deal with other doctest issues in the meantime.
This is a squash of these commits:
- Highlight edition-specific keywords correctly in code blocks,
accounting for code block edition modifiers
- Fix unit tests
- Revert changes to rustc_span::symbol to prepare for merge of #80272
- Use new Symbol::is_reserved API from #80272
- Remove unused import added by accident when merging
Move tooltips messages out of html
First thing first: nothing in the output has changed. You still have the "i" on the left of code blocks examples when they have `ignore`, `compile_fail`, `should_panic` and `edition`. The behavior also remains the same: when you hover the "i", you have the corresponding message showing up.
So now, why this PR then? I realized recently that we were actually generating those messages into the HTML every time whereas all messages are the same (except for the edition ones, I'll come back to it later). So instead of generating more content, I simply moved it inside the CSS thanks to pseudo elements (`::before` and `::after`). The message is now inside `::after` and we use the `::before` to have the small triangle on the left of the message. So now, we have less HTML generated which is seems pretty nice.
So now, back to the `edition` change: the message is globally the same, but the "edition" itself can be different (2015 or 2018 currently, I expect 2021 to arrive not too far in the future). So the only difference for it is that I added a new attribute on the tooltip called `edition` which contains this information. Then, the `::after` uses it inside its `content` (you can get the content of an element's attribute by using `attr` and concat different strings by simply having them after the other).
Don't hesitate if a part of my explanations isn't clear.
r? `@jyn514`
Rework beautify_doc_string so that it returns a Symbol instead of a String
This commit comes from https://github.com/rust-lang/rust/pull/80261, the goal here is to inspect the impact on performance of this change on its own.
The idea of rewriting `beautify_doc_string` is to not go through `String` if we don't need to update the doc comment to be able to keep the original `Symbol` and also to have better performance.
r? `@jyn514`
Remove `DefPath` from `Visibility` and calculate it on demand
Depends on #80090 and should not be merged before. Helps with https://github.com/rust-lang/rust/issues/79103 and https://github.com/rust-lang/rust/issues/76382.
cc https://github.com/rust-lang/rust/pull/80014#issuecomment-746810284 - `@nnethercote` I figured it out! It was simpler than I expected :)
This brings the size of `clean::Visibility` down from 40 bytes to 8.
Note that this does *not* remove `clean::Visibility`, even though it's now basically the same as `ty::Visibility`, because the `Invsible` variant means something different from `Inherited` and I thought it would be be confusing to merge the two. See the new comments on `impl Clean for ty::Visibility` for details.
Cleanup markdown span handling
1. Get rid of `locate()` in markdown handling
This function was unfortunate for several reasons:
- It used `unsafe` because it wanted to tell whether a string came from
the same *allocation* as another, not just whether it was a textual match.
- It recalculated spans even though they were already available from pulldown
- It sometimes *failed* to calculate the span, which meant it was always possible for the span to be `None`, even though in practice that should never happen.
This has several cleanups:
- Make the span required
- Pass through the span from pulldown in the `HeadingLinks` and `Footnotes` iterators
- Only add iterator bounds on the `impl Iterator`, not on `new` and the struct itself.
2. Remove unnecessary scope in `markdown_links`
I recommend reading a single commit at a time.
cc ``@bugadani`` - this will conflict with https://github.com/rust-lang/rust/pull/77859, I'll try to make sure that gets merged first.
This function was unfortunate for several reasons:
- It used `unsafe` because it wanted to tell whether a string came from
the same *allocation* as another, not just whether it was a textual
match.
- It recalculated spans even though they were already available from
pulldown
- It sometimes *failed* to calculate the span, which meant it was always
possible for the span to be `None`, even though in practice that
should never happen.
This commit has several cleanups:
- Make the span required
- Pass through the span from pulldown in the `HeadingLinks` and
`Footnotes` iterators
- Only add iterator bounds on the `impl Iterator`, not on `new` and the
struct itself.
Make BoundRegion have a kind of BoungRegionKind
Split from #76814
Also includes making `replace_escaping_bound_vars` only return `T`
Going to r? `@lcnr`
Feel free to reassign
Continue String to Symbol conversion in rustdoc (2)
Follow-up of #80119.
This is the last one (and I actually expected more conversions but seems like it was the last one remaining...).
r? `@jyn514`
Continue String to Symbol conversion in rustdoc
Follow-up of https://github.com/rust-lang/rust/pull/80091.
This PR is already big enough so I'll stop here before the next one.
r? `@jyn514`
Use more symbols in rustdoc
Builds on https://github.com/rust-lang/rust/pull/80044 and should not be merged before.
I want to test if this is actually faster before merging it, there was a lot of `to_string()` calls so I'm not sure it will actually help. That means I have to wait for 80044 to get merged before running perf.
r? `@ghost`
