Uh oh!
There was an error while loading. Please reload this page.
Implement RFC 1946 - intra-rustdoc links - #47046
Conversation
rust-highfive
commented
Dec 28, 2017
(rust_highfive has picked a reviewer for you, use r? to override) |
| pub struct RustdocVisitor<'a, 'tcx: 'a> { | ||
| cstore: &'tcx CrateStore, | ||
| pub struct RustdocVisitor<'a, 'b: 'a, 'tcx: 'b, 'rcx: 'b> { |
There was a problem hiding this comment.
Investigate whether 'b is actually needed.
| /// specific rustdoc annotations into account (i.e. `doc(hidden)`) | ||
| pub struct LibEmbargoVisitor<'a, 'b: 'a, 'tcx: 'b> { | ||
| cx: &'a ::core::DocContext<'b, 'tcx>, | ||
| pub struct LibEmbargoVisitor<'a, 'b: 'a, 'tcx: 'b, 'rcx: 'b> { |
There was a problem hiding this comment.
Would be neat if we can remove 'b here.
| html_favicon_url = "https://doc.rust-lang.org/favicon.ico", | ||
| html_root_url = "https://doc.rust-lang.org/nightly/", | ||
| html_playground_url = "https://play.rust-lang.org/")] | ||
| #![deny(warnings)] |
QuietMisdreavus
commented
Dec 28, 2017
I got @eddyb's remarks, a couple nits of my own, and the tidy errors. I also updated it to work with Hoedown as well. I'd like to add a few tests before i'm ready to call it good. |
QuietMisdreavus
commented
Dec 28, 2017
This current travis failure: Somehow, one of the markdown changes has affected how item summaries are rendered. It looks like whatever happened to the Pulldown rendering made it strip out the "Read more" link on things like trait method descriptions. Investigating... |
Do we need to implement this this way? Bear in mind that edit: reread the spec, this is for both cases |
Manishearth
commented
Dec 29, 2017
My hunch was correct; fixed the "read more" bug. |
Thinking about the shorthand more: Neither hoedown or pulldown let us intercept (It is not hard to make this work if we're allowed to edit hoedown and pulldown. I'd rather not.) |
Manishearth
commented
Dec 29, 2017
Handled error recovery |
Manishearth
commented
Dec 29, 2017
One thing that's missing is that if you try resolving an enum variant it will link to the enum, and if you try resolving a method it won't work at all. Haven't looked into that.
|
Manishearth
commented
Dec 29, 2017
Btw, foreign items do not work. Also, because we generate the module page before its items, the cache isn't populated when we attempt to generate the markdown for the module page, and We probably need to hook directly into the stuff populating the cache for this to work. I'm not sure how easy that is. |
QuietMisdreavus
commented
Dec 29, 2017
@Manishearth What situation are you seeing where the cache isn't there? The test i added works. Is it when you're linking to stuff in submodules? Unless i'm mistaken, the stuff in the cache that it's looking through should be populated in the previous stage of documentation. If it's not, it shouldn't be difficult to move it there. |
Manishearth
commented
Dec 29, 2017
via email
The situation was when you're doing a link in the first line and you're
looking at the short oneline summary docs on the module page. I don't know
if it's a cache issue; I haven't investigated. I assumed it was a cache
issue since the link resolves correctly on the item page and we don't do
relative paths yet so it should be the exact same code running. …On Dec 29, 2017 9:35 PM, "QuietMisdreavus" ***@***.***> wrote:
@Manishearth <https://github.com/manishearth> What situation are you
seeing where the cache isn't there? The test i added works. Is it when
you're linking to stuff in submodules?
Unless i'm mistaken, the stuff in the cache that it's looking through
should be populated in the previous stage of documentation. If it's not, it
shouldn't be difficult to move it there.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#47046 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABivSFlDq1gWvtaWjDsTQuSmAYqRBduOks5tFQ2_gaJpZM4ROPwe>
.
|
QuietMisdreavus
commented
Dec 29, 2017
Is it the same issue as #38386? Summary lines on trait methods haven't had links ever, but i don't remember offhand if module item summaries do the same thing. |
Manishearth
commented
Dec 30, 2017
via email
No so it shows up as a link, just that it's a link to ::foo, not
fun.foo.html or whatever. I think links in mod have worked. …On Dec 30, 2017 3:22 AM, "QuietMisdreavus" ***@***.***> wrote:
Is it the same issue as #38386
<#38386>? Summary lines on trait
methods haven't had links ever, but i don't remember offhand if module item
summaries do the same thing.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#47046 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABivSE9u1hTNTvo1M5ANUmNFrvLHZIOeks5tFV8CgaJpZM4ROPwe>
.
|
Manishearth
commented
Jan 1, 2018
Gah, it was a silly bug, we were pulling stuff off the wrong item. My bad. |
Manishearth
commented
Jan 1, 2018
@QuietMisdreavus happy new year Manishearth@7effbeb 😄 🎉 |
Manishearth
commented
Jan 1, 2018
I don't have a satisfactory solution for cross-crate inlining. What we could do is shove a .links map somewhere in the target dir and reuse that, i guess. |
QuietMisdreavus
commented
Jan 2, 2018
The way we solved cross-crate inlining for |
Manishearth
commented
Jan 2, 2018
Yeah, that won't work well here. We could design a good way of persisting such info cross crate in the output docdir somewhere. This does mean that such links will always be broken if you use the @eddyb do you have any suggestions? |
What you actually want to persist cross-crate is the scope information that lets you resolve names in a certain (module) scope, after the fact. It'd also allow not doing all the the resolver hacks. And there's a very good reason to want it in the compiler, at least same-crate: we could (finally) tell if a type is in scope somewhere so we can actually print So I think what you'll trying to do here is pretty cool, but maybe a bit ambitious at the moment? |
In that case perhaps we can land this without attempting to handle foreign items, and wait for a refactoring of resolution to do that. |
QuietMisdreavus
commented
Jan 5, 2018
I'm wary of landing this without cross-crate inlining, but if we can expedite the "really nice solution" that @eddyb mentioned, then it may be okay. There's enough here that's good, and it's not like the folder-path links are going away. (It just feels like an impotent feature without it, especially for something like std where it would help out the most. So! Before we rush to get this reviewed, let's take stock of what we wanted to have here and what we want to push to later implementation. (Specifically that checklist in the OP that we keep editing.) I'm going to give macro resolution a try. I gave it an initial shot last week, but my initial implementation wasn't working, so it may need to be postponed as well. @Manishearth What were you meaning with that one checklist item for "enums and UFCS methods"? Are enum variants and trait methods not available in the Resolver using |
QuietMisdreavus
commented
Jan 5, 2018
I just ran the test manually to debug the macro resolution and noticed a bunch of "rendering difference" errors. When i ran it with Pulldown, i noticed something off. Apparently, links with spaces in them don't work in commonmark at all. In this crate we would like to link to:
*[`ThisType`](struct ::ThisType)
*[`ThisEnum`](enum ::ThisEnum)
*[`ThisTrait`](trait ::ThisTrait)
*[`ThisAlias`](type ::ThisAlias)
*[`ThisUnion`](union ::ThisUnion)
*[`this_function`](::this_function())*[`THIS_CONST`](const ::THIS_CONST)
*[`THIS_STATIC`](static ::THIS_STATIC)<p>In this crate we would like to link to:</p><ul><li>[<code>ThisType</code>](struct ::ThisType)</li><li>[<code>ThisEnum</code>](enum ::ThisEnum)</li><li>[<code>ThisTrait</code>](trait ::ThisTrait)</li><li>[<code>ThisAlias</code>](type ::ThisAlias)</li><li>[<code>ThisUnion</code>](union ::ThisUnion)</li><li><ahref="::this_function()"><code>this_function</code></a></li><li>[<code>THIS_CONST</code>](const ::THIS_CONST)</li><li>[<code>THIS_STATIC</code>](static ::THIS_STATIC)</li></ul>This completely renders the "path ambiguity" qualifiers useless because right now they'll generate a bunch of rendering warnings, and once we take out Hoedown they'll take out the links entirely. Our options are (1) taking them out, or (2) using something other than the space to separate the qualifier from the path. Something like |
eddyb
commented
Jan 5, 2018
I've suggested unified pages before, such that you'd have |
bors
commented
Jan 22, 2018
💔 Test failed - status-travis |
QuietMisdreavus
commented
Jan 22, 2018
I... have no idea where this even is. There's no file listed here. |
QuietMisdreavus
commented
Jan 22, 2018
Found the culprit, but again, i'm not sure how this got here. rust/src/librustc/middle/region.rs Lines 349 to 356 in fdc18b3 I feel like this should have been caught in the main #46278 PR? |
ollie27
commented
Jan 22, 2018
Those docs are on a private field so prior to this PR they weren't rendered at all. Now they are "rendered" to look for links. The |
QuietMisdreavus
commented
Jan 22, 2018
Good catch! I just pushed a commit to bypass processing code blocks in |
Manishearth
commented
Jan 23, 2018
@bors r=eddyb,GuillaumeGomez,QuietMisdreavus,Manishearth New commit lgtm |
bors
commented
Jan 23, 2018
📌 Commit 63811b6 has been approved by |
bors
commented
Jan 23, 2018
…Gomez,QuietMisdreavus,Manishearth Implement RFC 1946 - intra-rustdoc links rust-lang/rfcs#1946#43466 Note for reviewers: The plain line counts are a little inflated because of how the markdown link parsing was done. [Read the file diff with "whitespace only" changes removed](https://github.com/rust-lang/rust/pull/47046/files?w=1) to get a better view of what actually changed there. This pulls the name/path resolution mechanisms out of the compiler and runs it on the markdown in a crate's docs, so that links can be made to `SomeStruct` directly rather than finding the folder path to `struct.SomeStruct.html`. Check the `src/test/rustdoc/intra-paths.rs` test in this PR for a demo. The change was... a little invasive, but unlocks a really powerful mechanism for writing documentation that doesn't care about where an item was written to on the hard disk. Items included: - [x] Make work with the hoedown renderer - [x] Handle relative paths - [x] Parse out the "path ambiguities" qualifiers (`[crate foo]`, `[struct Foo]`, `[foo()]`, `[static FOO]`, `[foo!]`, etc) - [x] Resolve foreign macros - [x] Resolve local macros - [x] Handle the use of inner/outer attributes giving different resolution scopes (handling for non-modules pushed to different PR) Items not included: - [ ] Make sure cross-crate inlining works (blocked on refactor described in #47046 (comment)) - [ ] Implied Shortcut Reference Links (where just doing `[::std::iter::Iterator][]` without a reference anchor will resolve using the reference name rather than the link target) (requires modifying the markdown parser - blocked on Hoedown/Pulldown switch and pulldown-cmark/pulldown-cmark#121) - [ ] Handle enum variants and UFCS methods (Enum variants link to the enum page, associated methods don't link at all) - [ ] Emit more warnings/errors when things fail to resolve (linking to a value-namespaced item without a qualifier will emit an error, otherwise the link is just treated as a url, not a rust path) - [ ] Give better spans for resolution errors (currently the span for the first doc comment is used) - [ ] Check for inner doc comments on things that aren't modules I'm making the PR, but it should be noted that most of the work was done by Misdreavus 😄 (Editor's note: This has become a lie, check that commit log, Manish did a ton of work after this PR was opened `>_>`)
bors
commented
Jan 23, 2018
☀️ Test successful - status-appveyor, status-travis |
Manishearth
commented
Jan 23, 2018
WOOOOOOOOOO |
sgrif
commented
Jan 23, 2018
So will this "just work" if I compile master and try it out? Is it feature gated somehow? |
Manishearth
commented
Jan 23, 2018
Yep, it should just work. It's nightly-gated; so if you try this with a stable compiler in 12 weeks stuff won't look great. |
sgrif
commented
Jan 23, 2018
👍 time to compile from master then. My office was getting a tad cold anyway. |
sgrif
commented
Jan 23, 2018
Hm is there additional magic I have to do for this? I tried changing a line that was to but it just leaves |
Can't check, but shouldn't there be brackets somewhere? Like (e) No idea how to get the backticks correct, but I guess everyone can guess what I mean... |
sgrif
commented
Jan 23, 2018
Yes, the actual link in the text appears as |
QuietMisdreavus
commented
Jan 23, 2018
Is the |
sgrif
commented
Jan 23, 2018
Gotcha. Changing it to |
… r=QuietMisdreavus rustdoc: Fix link title rendering with hoedown The link title needs to be HTML escaped. It was broken by rust-lang#47046. r? @QuietMisdreavus
rust-lang/rfcs#1946#43466
Note for reviewers: The plain line counts are a little inflated because of how the markdown link parsing was done. Read the file diff with "whitespace only" changes removed to get a better view of what actually changed there.
This pulls the name/path resolution mechanisms out of the compiler and runs it on the markdown in a crate's docs, so that links can be made to
SomeStructdirectly rather than finding the folder path tostruct.SomeStruct.html. Check thesrc/test/rustdoc/intra-paths.rstest in this PR for a demo. The change was... a little invasive, but unlocks a really powerful mechanism for writing documentation that doesn't care about where an item was written to on the hard disk.Items included:
[crate foo],[struct Foo],[foo()],[static FOO],[foo!], etc)Items not included:
[::std::iter::Iterator][]without a reference anchor will resolve using the reference name rather than the link target) (requires modifying the markdown parser - blocked on Hoedown/Pulldown switch and Option to insert reference link definitions on demand pulldown-cmark/pulldown-cmark#121)I'm making the PR, but it should be noted that most of the work was done by Misdreavus 😄
(Editor's note: This has become a lie, check that commit log, Manish did a ton of work after this PR was opened
>_>)