Docs.rs: [src] view shows lines first and then the code.
Clicking on the [src] link for any repo shows you first the line numbers and then the source code.
For example here: https://docs.rs/spirv-reflect/0.1.2/src/spirv_reflect/lib.rs.html#1-601
I get this on Firefox 63.0.3:
AlexEne
All 16 comments
This is an upstream rustdoc bug that should have been fixed by https://github.com/rust-lang/rust/pull/55493, so i'm surprised it showed up on the nightly that rendered these docs (rustc 1.32.0-nightly (6b9b97bd9 2018-11-15)). I'm confident that upstream docs weren't having this problem on that nightly - is there some other interaction that's going on? @GuillaumeGomez, is there a way to find out?
QuietMisdreavus
on 20 Nov 2018
It comes from my add of line numbers and it has been fixed already in https://github.com/rust-lang/rust/pull/55858.
GuillaumeGomez
on 20 Nov 2018
Is it possible that the documentation will be rebuilt that has been generated in that date region?
hellow554
on 26 Nov 2018
It's not fixed, though. I just updated the nightly used to build crates to 1.32.0-nightly (3e90a12a8 2018-11-29) and it still exhibits this issue. It's possible for us to rebuild these crates, but i'd wait until we've properly fixed the issue for docs.rs first.
QuietMisdreavus
on 30 Nov 2018
It is fixed as far as I can tell. For instance: https://doc.rust-lang.org/nightly/src/alloc/string.rs.html#294-296 (but maybe it requires to update to a more recent rustdoc version?)
GuillaumeGomez
on 1 Dec 2018
@GuillaumeGomez It's still broken on docs.rs though. I rebuilt the crate mentioned in the issue description with the rustdoc i just mentioned, and it still shows the problem - click the link and see for yourself.
QuietMisdreavus
on 1 Dec 2018
A few things are different in the style apparently:
+ body:not(.source) .example-wrap>pre.rust {
+ width: 100%;
+ }
+ body:not(.source) .example-wrap {
+ display: inline-flex;
+ }
I don't see that difference? I just compared with https://docs.rs/spirv-reflect/0.1.2/rustdoc-20181129-1.32.0-nightly-3e90a12a8.css with https://github.com/rust-lang/rust/blob/d09466ceb1374bd0ff1c490bfd50133b8ca67558/src/librustdoc/html/static/rustdoc.css (after trying to un-minimize the former) and i don't see any significant differences between them.
QuietMisdreavus
on 1 Dec 2018
Looking further, it seems like the problem is in that CSS selector, body:not(.source), since that affects this behavior. On docs.rs, the <body> tag doesn't get any of the classes that rustdoc sets for it, since it needs to wrap it to insert the navigation bar. Instead, the site content is in a top-level <div class="rustdoc container-rustdoc">. Because the CSS is looking for classes on the <body> tag, that won't work on docs.rs. I'm not sure the best way to approach it, but changing the way those selectors apply will fix the CSS for docs.rs.
QuietMisdreavus
on 1 Dec 2018
I looked at 0.1.6 version. And by updating the CSS (by removing the 2 rules that shouldn't be there), it worked as expected.
GuillaumeGomez
on 1 Dec 2018
You mean these rules that are also in nightly? Is there a PR on rust-lang/rust that fixes that?
QuietMisdreavus
on 1 Dec 2018
This PR added those rules. But it was supposed to fix this very issue. How weird...
GuillaumeGomez
on 1 Dec 2018
We talked about it on Discord:
- The CSS on upstream rustdoc's side was too restrictive, so https://github.com/rust-lang/rust/pull/56416 was opened to allow it to work with the way docs.rs structures its docs pages.
- However, docs.rs doesn't actually save the CSS classes that rustdoc applies to the
<body>tag, so this won't even work until we fix that. If we change the HTML extraction code to also grab the classes off the body tag, then add them to the rustdoc template in therustdoc-containerdiv, it will start adding thesourceclass to the tree that the new CSS rules will use. (The HTML extraction is called here and inserted into the template, so that's where the body classes would also have to be captured.)
I'm planning to work on the latter later today, but if i don't get to it then that's at least what i think the solution should be.
QuietMisdreavus
on 1 Dec 2018
Still broken for me: https://docs.rs/tokio-udp/0.1.3/src/tokio_udp/socket.rs.html#392-396
MOZGIII
on 25 Mar 2019
This is because tokio-udp has been built before this fix was merged. It needs to be rebuilt. This can either be triggered manually by the docs team (afaik) or by pushing a newer version. You probably should open a ticket at tokio-udp and explain it.
hellow554
on 25 Mar 2019
Why can't docs.rs just issue regeneration for all broken crates? Until all the affected crates' docs are updated it's not fixed anyhow. And I've seen a lot of broken crates.
In my view it's not fair to make crate authors look after what's going on with their at docs.rs - in a sense that if docs.rs has bugged renders it should not be the responsibility of the people that had nothing to do with the infra of the docs.rs.
Plus, it would be almost impossible to get rid of the problem once and for all, if not via the centralized approach. I bet it's not that hard to regenerate the docs for the docs.rs team - even for non-last versions, that are important too.
MOZGIII
on 25 Mar 2019
Related issues
nhristov
路
3Comments
stefan-k
路
6Comments
nagisa
路
4Comments
Nemo157
路
4Comments
lopopolo
路
5Comments
Most helpful comment
We talked about it on Discord:
<body>tag, so this won't even work until we fix that. If we change the HTML extraction code to also grab the classes off the body tag, then add them to the rustdoc template in therustdoc-containerdiv, it will start adding thesourceclass to the tree that the new CSS rules will use. (The HTML extraction is called here and inserted into the template, so that's where the body classes would also have to be captured.)I'm planning to work on the latter later today, but if i don't get to it then that's at least what i think the solution should be.