| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fix rustdoc test ICE
Fixes #48377.
r? @QuietMisdreavus
|
|
Implement implied shortcut links for intra-rustdoc-links
cc https://github.com/rust-lang/rust/issues/43466
Needs https://github.com/google/pulldown-cmark/pull/126
r? @QuietMisdreavus
|
|
|
|
This removes the implicit dependency on the iteration
order of FxHashMap
|
|
|
|
|
|
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
|
|
fix more typos found by codespell.
|
|
Remove hoedown from rustdoc
Finally the time has come!
r? @QuietMisdreavus
|
|
|
|
add unit tests for rustdoc's processing of doctests
cc #42018
There's a lot of things that rustdoc will do to massage doctests into something that can be compiled, and a lot of options that can be toggled to affect this. Hopefully this list of tests can show off that functionality.
The first commit is slightly unrelated but doesn't touch public functionality, because i found that if you have a manual `fn main`, it adds an extra line break at the end, whereas it would trim this extra line break if it were putting a `fn main` in automatically. That first commit makes it trim out that whitespace ahead of time.
|
|
Is it really time? Have our months, no, *years* of suffering come to an end? Are we finally able to cast off the pall of Hoedown? The weight which has dragged us down for so long?
-----
So, timeline for those who need to catch up:
* Way back in December 2016, [we decided we wanted to switch out the markdown renderer](https://github.com/rust-lang/rust/issues/38400). However, this was put on hold because the build system at the time made it difficult to pull in dependencies from crates.io.
* A few months later, in March 2017, [the first PR was done, to switch out the renderers entirely](https://github.com/rust-lang/rust/pull/40338). The PR itself was fraught with CI and build system issues, but eventually landed.
* However, not all was well in the Rustdoc world. During the PR and shortly after, we noticed [some differences in the way the two parsers handled some things](https://github.com/rust-lang/rust/issues/40912), and some of these differences were major enough to break the docs for some crates.
* A couple weeks afterward, [Hoedown was put back in](https://github.com/rust-lang/rust/pull/41290), at this point just to catch tests that Pulldown was "spuriously" running. This would at least provide some warning about spurious tests, rather than just breaking spontaneously.
* However, the problems had created enough noise by this point that just a few days after that, [Hoedown was switched back to the default](https://github.com/rust-lang/rust/pull/41431) while we came up with a solution for properly warning about the differences.
* That solution came a few weeks later, [as a series of warnings when the HTML emitted by the two parsers was semantically different](https://github.com/rust-lang/rust/pull/41991). But that came at a cost, as now rustdoc needed proc-macro support (the new crate needed some custom derives farther down its dependency tree), and the build system was not equipped to handle it at the time. It was worked on for three months as the issue stumped more and more people.
* In that time, [bootstrap was completely reworked](https://github.com/rust-lang/rust/pull/43059) to change how it ordered compilation, and [the method by which it built rustdoc would change](https://github.com/rust-lang/rust/pull/43482), as well. This allowed it to only be built after stage1, when proc-macros would be available, allowing the "rendering differences" PR to finally land.
* The warnings were not perfect, and revealed a few [spurious](https://github.com/rust-lang/rust/pull/44368) [differences](https://github.com/rust-lang/rust/pull/45421) between how we handled the renderers.
* Once these were handled, [we flipped the switch to turn on the "rendering difference" warnings all the time](https://github.com/rust-lang/rust/pull/45324), in October 2017. This began the "warning cycle" for this change, and landed in stable in 1.23, on 2018-01-04.
* Once those warnings hit stable, and after a couple weeks of seeing whether we would get any more reports than what we got from sitting on nightly/beta, [we switched the renderers](https://github.com/rust-lang/rust/pull/47398), making Pulldown the default but still offering the option to use Hoedown.
And that brings us to the present. We haven't received more new issues from this in the meantime, and the "switch by default" is now on beta. Our reasoning is that, at this point, anyone who would have been affected by this has run into it already.
|
|
rustdoc: Hide `-> ()` in cross crate inlined Fn* bounds
|
|
|
|
|
|
Fix rustdoc ICE on macros defined within functions
fixes #47639
|
|
|
|
|
|
The link title needs to be HTML escaped.
|
|
|
|
|
|
Rollup of 14 pull requests
- Successful merges: #47423, #47425, #47440, #47541, #47549, #47554, #47558, #47610, #47635, #47655, #47661, #47662, #47667, #47672
- Failed merges:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
rustdoc: Populate external_traits with traits only seen in impls
This means default methods can always be found and "Important traits" will include all spotlight traits.
|
|
|
|
|
|
This means default methods can always be found and "Important traits" will include all spotlight traits.
|
|
rustdoc: Don't import macros from private imports
Fixes #47038
|
|
zackmdavis:the_3rd_of_2_hardest_problems_in_computer_science, r=QuietMisdreavus
fix the doc-comment-decoration-trimming edge-case rustdoc ICE
This `horizontal_trim` function strips the leading whitespace from
doc-comments that have a left-asterisk-margin:
```
/**
* You know what I mean—
*
* comments like this!
*/
```
The index of the column of asterisks is `i`, and if trimming is deemed
possible, we slice each line from `i+1` to the end of the line. But if, in
particular, `i` was 0 _and_ there was an empty line (as in the example
given in the reporting issue), we ended up panicking trying to slice an
empty string from 0+1 (== 1).
Let's tighten our check to say that we can't trim when `i` is even the same
as the length of the line, not just when it's greater. (Any such cases
would panic trying to slice `line` from `line.len()+1`.)
Resolves #47197.
|
|
|
|
rustdoc: Add missing src links for generic impls on trait pages
`implementor2item` would return `None` for generic impls so instead this clones the entire `clean::Item` into the `implementors` map which simplifies some code.
|
|
This `horizontal_trim` function strips the leading whitespace from
doc-comments that have a left-asterisk-margin:
/**
* You know what I mean—
*
* comments like this!
*/
The index of the column of asterisks is `i`, and if trimming is deemed
possible, we slice each line from `i+1` to the end of the line. But if, in
particular, `i` was 0 _and_ there was an empty line (as in the example
given in the reporting issue), we ended up panicking trying to slice an
empty string from 0+1 (== 1).
Let's tighten our check to say that we can't trim when `i` is even the same
as the length of the line, not just when it's greater. (Any such cases
would panic trying to slice `line` from `line.len()+1`.)
Resolves #47197.
|
|
Issue 46976
ICE is due to an empty path segments, so I set the path to be the same as the in band ty params symbol. (I think this is how regular generics end up being handled?)
Pinging @cramertj, this is your code I'm editing here.
|
|
|
|
|
|
The modules may be private or may even be enums so it would generate dead links.
|
|
`implementor2item` would return `None` for generic impls so instead this clones the entire `clean::Item` into the `implementors` map which simplifies some code.
|
|
Const-eval array lengths in rustdoc.
Fixes #46727
r? @eddyb
Big thanks to @eddyb for helping me figure this out.
|
|
|
|
tweaks and fixes for doc(include)
This PR makes a handful of changes around `#[doc(include="file.md")]` (https://github.com/rust-lang/rust/issues/44732):
* Turns errors when loading files into full errors. This matches the original RFC text.
* Makes the `missing_docs` lint check for `#[doc(include="file.md")]` as well as regular `#[doc="text"]` attributes.
* Loads files included by `#[doc(include="file.md")]` into dep-info, mirroring the behavior of `include_str!()` and friends.
* Adds or modifies tests to check for all of these.
|
|
Escape more items in the sidebar when needed
Fixes #46724.
r? @QuietMisdreavus
|
|
|
|
Add an option to allow rustdoc to list modules by appearance
The `--sort-modules-by-appearance` option will list modules in the
order that they appear in the source, rather than sorting them
alphabetically (as is the default). This resolves #8552.
|
|
Do not display hidden types, fixes issue 23912
Fixes #23912.
r? @QuietMisdreavus
(It's the one I was talking about a few days ago, just close it if it's useless.)
|
|
|
