Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[src] view shows lines first and then the code. #264

Closed
AlexEne opened this issue Nov 20, 2018 · 16 comments
Closed

[src] view shows lines first and then the code. #264

AlexEne opened this issue Nov 20, 2018 · 16 comments

Comments

@AlexEne
Copy link
Member

AlexEne commented Nov 20, 2018

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:

image

@QuietMisdreavus
Copy link
Member

This is an upstream rustdoc bug that should have been fixed by rust-lang/rust#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?

@GuillaumeGomez
Copy link
Member

It comes from my add of line numbers and it has been fixed already in rust-lang/rust#55858.

@hellow554
Copy link

Is it possible that the documentation will be rebuilt that has been generated in that date region?

@QuietMisdreavus
Copy link
Member

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.

@GuillaumeGomez
Copy link
Member

GuillaumeGomez commented Dec 1, 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?)

@QuietMisdreavus
Copy link
Member

@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.

@GuillaumeGomez
Copy link
Member

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;
+ }

@QuietMisdreavus
Copy link
Member

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
Copy link
Member

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.

@GuillaumeGomez
Copy link
Member

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.

@QuietMisdreavus
Copy link
Member

You mean these rules that are also in nightly? Is there a PR on rust-lang/rust that fixes that?

@GuillaumeGomez
Copy link
Member

This PR added those rules. But it was supposed to fix this very issue. How weird...

@QuietMisdreavus
Copy link
Member

We talked about it on Discord:

  • The CSS on upstream rustdoc's side was too restrictive, so Remove unneeded body class selector rust#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 the rustdoc-container div, it will start adding the source class 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.

@MOZGIII
Copy link

MOZGIII commented Mar 24, 2019

@hellow554
Copy link

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.

@MOZGIII
Copy link

MOZGIII commented Mar 25, 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants