Revert "Cleanup markdown span handling"
Reverts rust-lang/rust#80244. This caused a diagnostic regression, originally it was:
```
warning: unresolved link to `std::process::Comman`
--> link.rs:3:10
|
3 | //! [a]: std::process::Comman
| ^^^^^^^^^^^^^^^^^^^^ no item named `Comman` in module `process`
|
= note: `#[warn(broken_intra_doc_links)]` on by default
```
but after that PR rustdoc now displays
```
warning: unresolved link to `std::process::Comman`
--> link.rs:1:14
|
1 | //! Links to [a] [link][a]
| ^^^ no item named `Comman` in module `process`
|
= note: `#[warn(broken_intra_doc_links)]` on by default
```
which IMO is much less clear.
cc `@bugadani,` thanks for catching this in https://github.com/rust-lang/rust/pull/77859.
r? `@GuillaumeGomez`
This caused a diagnostic regression, originally it was:
```
warning: unresolved link to `std::process::Comman`
--> link.rs:3:10
|
3 | //! [a]: std::process::Comman
| ^^^^^^^^^^^^^^^^^^^^ no item named `Comman` in module `process`
|
= note: `#[warn(broken_intra_doc_links)]` on by default
```
but after that PR rustdoc now displays
```
warning: unresolved link to `std::process::Comman`
--> link.rs:1:14
|
1 | //! Links to [a] [link][a]
| ^^^ no item named `Comman` in module `process`
|
= note: `#[warn(broken_intra_doc_links)]` on by default
```
which IMO is much less clear.
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`
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`
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.
Previously Markdown documentation was not rendered to HTML for search results,
which led to the output not being very readable, particularly for inline code.
This PR fixes that by rendering Markdown to HTML with the help of pulldown-cmark
(the library rustdoc uses to parse Markdown for the main text of documentation).
However, the text for the title attribute (the text shown when you hover over an
element) still uses the plain-text rendering since it is displayed in browsers
as plain-text.
Only these styles will be rendered; everything else is stripped away:
* *italics*
* **bold**
* `inline code`
We have a similar function `opts()` that is for rendering the main body
of the documentation, but until now we just constructed the options for
rendering summaries on the fly. This is a problem if/when we change the
enabled options since the different places can get out-of-sync.
rustdoc has various user-configurable preferences. These are recorded
in web Local Storage (where available). But we want to provide a way
to configure the default default, including for when web storage is
not available.
getSettingValue is the function responsible for looking up these
settings. Here we make it fall back some in-DOM data, which
ultimately comes from RenderOptions.default_settings.
Using HTML data atrtributes is fairly convenient here, dsspite the
need to transform between snake and kebab case to avoid the DOM
converting kebab case to camel case (!)
We cache the element and dataset lookup in a global variable, to
ensure that getSettingValue remains fast.
The DOM representation has to be in an element which precedes the
inclusion of storage.js. That means it has to be in the <head> and we
should not use an empty <div> as the container (although most browsers
will accept that). An empty <script> element provides a convenient
and harmless container object. <meta> would be another possibility
but runs a greater risk of having unwanted behaviours on weird
browsers.
We trust the RenderOptions not to contain unhelpful setting names,
which don't fit nicely into an HTML attribute. It's awkward to quote
dataset keys.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Thanks to marcusklaas' hard work in https://github.com/raphlinus/pulldown-cmark/pull/469, this fixes a lot of rustdoc bugs!
- Get rid of unnecessary `RefCell`
- Fix duplicate warnings for broken implicit reference link
- Remove unnecessary copy of links
Remove disambiguators from intra doc link text
Closes https://github.com/rust-lang/rust/issues/65354.
r? @Manishearth
The commits are mostly atomic, but there might be some mix between them here and there. I recommend reading 'refactor ItemLink' and 'refactor RenderedLink' on their own though, lots of churn without any logic changes.
- Preserve suffixes when displaying
- Rename test file to match `intra-link*`
- Remove unnecessary .clone()s
- Improve comments and naming
- Fix more bugs and add tests
- Escape intra-doc link example in public documentation
rustdoc: do not use plain summary for trait impls
Fixes#38386.
Fixes#48332.
Fixes#49430.
Fixes#62741.
Fixes#73474.
Unfortunately this is not quite ready to go because the newly-working links trigger a bunch of linkcheck failures. The failures are tough to fix because the links are resolved relative to the implementor, which could be anywhere in the module hierarchy.
(In the current docs, these links end up rendering as uninterpreted markdown syntax, so I don't think these failures are any worse than the status quo. It might be acceptable to just add them to the linkchecker whitelist.)
Ideally this could be fixed with intra-doc links ~~but it isn't working for me: I am currently investigating if it's possible to solve it this way.~~ Opened #73829.
EDIT: This is now ready!
Related to https://github.com/rust-lang/rust/issues/65354
- Pass through the replacement text to `markdown.rs`
- Add some tests
- Add a state machine that actually replaces the text when parsing Markdown
This modules contains the implementation of doctests, and not the
tests of rustdoc itself. This name is confusing, so let's rename it to
doctest for clarity.
Previously, compile_fail and ignore code examples displayed a tooltip
indicating this in the documentation. This tooltip has now also been
added to should_panic examples.
use is_empty() instead of len comparison (clippy::len_zero)
use if let instead of while let loop that never loops (clippy::never_loop)
remove redundant returns (clippy::needless_return)
remove redundant closures (clippy::redundant_closure)
use if let instead of match and wildcard pattern (clippy::single_match)
don't repeat field names redundantly (clippy::redundant_field_names)
