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

rustdoc: Render [src] links for trait implementors #44920

Merged
merged 5 commits into from Oct 3, 2017

Conversation

Projects
None yet
6 participants
@vi
Contributor

vi commented Sep 29, 2017

Should close #43893.

No tests [yet].

r? @QuietMisdreavus

vi added some commits Sep 29, 2017

@rust-highfive

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Sep 29, 2017

Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @QuietMisdreavus (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

Collaborator

rust-highfive commented Sep 29, 2017

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @QuietMisdreavus (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@shepmaster

This comment has been minimized.

Show comment
Hide comment
@shepmaster

shepmaster Sep 29, 2017

Member

No tests [yet].

Do you expect there to be tests in this PR? I'm going to assume "yes" and mark this as effectively a WIP.

Member

shepmaster commented Sep 29, 2017

No tests [yet].

Do you expect there to be tests in this PR? I'm going to assume "yes" and mark this as effectively a WIP.

@QuietMisdreavus

This comment has been minimized.

Show comment
Hide comment
@QuietMisdreavus

QuietMisdreavus Sep 29, 2017

Member

The last time i added [src] links i didn't add tests for them, but i have discovered the test src/test/rustdoc/src-links.rs that ensures these are present for full-file links, or other tests like issue-34274.rs that checks this for specific place. If you want to set up a test for this you can use that latter file as a base, and i can walk you through it. (Personally i wouldn't gate the PR on them, but since other [src] links are tested it would be good to cover that.)

The PR as-is seems to put the links in a place where the CSS isn't expecting to style them. This leaves them looking weird when adjacent to other src links, like here on Iterator:

image

I'd like to get with @GuillaumeGomez to double-check what the best CSS change for this is, but I'm pretty sure that's all it will take to get these right.

Member

QuietMisdreavus commented Sep 29, 2017

The last time i added [src] links i didn't add tests for them, but i have discovered the test src/test/rustdoc/src-links.rs that ensures these are present for full-file links, or other tests like issue-34274.rs that checks this for specific place. If you want to set up a test for this you can use that latter file as a base, and i can walk you through it. (Personally i wouldn't gate the PR on them, but since other [src] links are tested it would be good to cover that.)

The PR as-is seems to put the links in a place where the CSS isn't expecting to style them. This leaves them looking weird when adjacent to other src links, like here on Iterator:

image

I'd like to get with @GuillaumeGomez to double-check what the best CSS change for this is, but I'm pretty sure that's all it will take to get these right.

@vi

This comment has been minimized.

Show comment
Hide comment
@vi

vi Sep 29, 2017

Contributor

No tests [yet].

Do you expect there to be tests in this PR? I'm going to assume "yes" and mark this as effectively a WIP.

If this is required. [yet] means "if needed per some rues there will also be a test, but if the change is too trivial and/or the test environment is too tricky to setup and/or there is some impending change devaluing existing tests then not".

Contributor

vi commented Sep 29, 2017

No tests [yet].

Do you expect there to be tests in this PR? I'm going to assume "yes" and mark this as effectively a WIP.

If this is required. [yet] means "if needed per some rues there will also be a test, but if the change is too trivial and/or the test environment is too tricky to setup and/or there is some impending change devaluing existing tests then not".

@QuietMisdreavus

This comment has been minimized.

Show comment
Hide comment
@QuietMisdreavus

QuietMisdreavus Sep 30, 2017

Member

Thanks for writing that test! The last thing i wanted to make sure this had was the CSS change we discussed on Gitter yesterday. @GuillaumeGomez suggested adding the following block to src/librustdoc/html/static/rustdoc.css:

ul.item-list > li > .out-of-band {
    font-size: 19px;
}

And then changing the part that sets the font-family for all the sans-serif text to add ul.item-list > li > .out-of-band to its list of targets. These changes will make sure the [src] links look like all the others, since the existing CSS missed these new ones.

Member

QuietMisdreavus commented Sep 30, 2017

Thanks for writing that test! The last thing i wanted to make sure this had was the CSS change we discussed on Gitter yesterday. @GuillaumeGomez suggested adding the following block to src/librustdoc/html/static/rustdoc.css:

ul.item-list > li > .out-of-band {
    font-size: 19px;
}

And then changing the part that sets the font-family for all the sans-serif text to add ul.item-list > li > .out-of-band to its list of targets. These changes will make sure the [src] links look like all the others, since the existing CSS missed these new ones.

@GuillaumeGomez

This comment has been minimized.

Show comment
Hide comment
@GuillaumeGomez

GuillaumeGomez Oct 1, 2017

Member

I don't even see any css update. Did you forgot to push the file?

Member

GuillaumeGomez commented Oct 1, 2017

I don't even see any css update. Did you forgot to push the file?

@vi

This comment has been minimized.

Show comment
Hide comment
@vi

vi Oct 1, 2017

Contributor

Saw the messages, implemented the CSS change.

Contributor

vi commented Oct 1, 2017

Saw the messages, implemented the CSS change.

@vi

This comment has been minimized.

Show comment
Hide comment
@vi

vi Oct 1, 2017

Contributor

Means "why not spaces"? Because of other indenting whitespace in this file is tabs.

Continued list of targets which was split into mutiple lines is additionally indented to avoid blending with the rules part which is singly indented.

Contributor

vi commented Oct 1, 2017

Means "why not spaces"? Because of other indenting whitespace in this file is tabs.

Continued list of targets which was split into mutiple lines is additionally indented to avoid blending with the rules part which is singly indented.

rustdoc: Style of [src] link for trait implementors
A change suggested by @GuillaumeGomez and @QuietMisdreavus.

Also slight reindenting of the appropriate CSS section.
@vi

This comment has been minimized.

Show comment
Hide comment
@vi

vi Oct 1, 2017

Contributor

Just put it on the next line and it's fine, no?

Mainly because of I didn't notice a precedent of multi-line target line nearby and just did as I usually do.

Fixed and re-pushed.

the need of the alignment

To allow assumption that each non-indented line is some section (oneline or multiline), not a continuation of something previous. But since non-indented style is already used elsewhere in the file, it's better to just follow it.

Contributor

vi commented Oct 1, 2017

Just put it on the next line and it's fine, no?

Mainly because of I didn't notice a precedent of multi-line target line nearby and just did as I usually do.

Fixed and re-pushed.

the need of the alignment

To allow assumption that each non-indented line is some section (oneline or multiline), not a continuation of something previous. But since non-indented style is already used elsewhere in the file, it's better to just follow it.

// ignore-cross-compile
#![crate_name = "foo"]

This comment has been minimized.

@GuillaumeGomez

GuillaumeGomez Oct 1, 2017

Member

Please remove all unneeded empty lines in here (like in the impl blocks).

@GuillaumeGomez

GuillaumeGomez Oct 1, 2017

Member

Please remove all unneeded empty lines in here (like in the impl blocks).

This comment has been minimized.

@vi

vi Oct 1, 2017

Contributor

Which empty lines? Before and after the // ignore-corss-compile? They are just retained from issue-34274.rs, which served as a template. I don't think they should be removed (especially the first empty line).

like in the impl blocks

Means "and likewise remove them in impl blocks" or "like you did in impl blocks"?

@vi

vi Oct 1, 2017

Contributor

Which empty lines? Before and after the // ignore-corss-compile? They are just retained from issue-34274.rs, which served as a template. I don't think they should be removed (especially the first empty line).

like in the impl blocks

Means "and likewise remove them in impl blocks" or "like you did in impl blocks"?

This comment has been minimized.

@GuillaumeGomez

GuillaumeGomez Oct 2, 2017

Member

Like this:

// Copyright 2016 The Rust Project Developers. See the COPYRIGHT
// file at the top-level directory of this distribution and at
// http://rust-lang.org/COPYRIGHT.
//
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
// option. This file may not be copied, modified, or distributed
// except according to those terms.

// ignore-cross-compile

#![crate_name = "foo"]

pub trait SomeTrait {}
pub struct SomeStruct;

// @has foo/trait.SomeTrait.html '//a/@href' '../src/foo/issue-43893.rs.html#23-26'
impl SomeTrait for usize {}

// @has foo/trait.SomeTrait.html '//a/@href' '../src/foo/issue-43893.rs.html#29-32'
impl SomeTrait for SomeStruct {}
@GuillaumeGomez

GuillaumeGomez Oct 2, 2017

Member

Like this:

// Copyright 2016 The Rust Project Developers. See the COPYRIGHT
// file at the top-level directory of this distribution and at
// http://rust-lang.org/COPYRIGHT.
//
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
// option. This file may not be copied, modified, or distributed
// except according to those terms.

// ignore-cross-compile

#![crate_name = "foo"]

pub trait SomeTrait {}
pub struct SomeStruct;

// @has foo/trait.SomeTrait.html '//a/@href' '../src/foo/issue-43893.rs.html#23-26'
impl SomeTrait for usize {}

// @has foo/trait.SomeTrait.html '//a/@href' '../src/foo/issue-43893.rs.html#29-32'
impl SomeTrait for SomeStruct {}

This comment has been minimized.

@vi

vi Oct 2, 2017

Contributor

impl SomeTrait for usize {}

{}

Other [src] link test (issue-34274.rs) tests for single line link. I thought it would be useful to also provide multiple line implementation, so that the link contains line range, not a single line.

@vi

vi Oct 2, 2017

Contributor

impl SomeTrait for usize {}

{}

Other [src] link test (issue-34274.rs) tests for single line link. I thought it would be useful to also provide multiple line implementation, so that the link contains line range, not a single line.

This comment has been minimized.

@QuietMisdreavus

QuietMisdreavus Oct 2, 2017

Member

Having multi-line tests is useful to make sure that the link points to the full span.

@QuietMisdreavus

QuietMisdreavus Oct 2, 2017

Member

Having multi-line tests is useful to make sure that the link points to the full span.

This comment has been minimized.

@vi

vi Oct 2, 2017

Contributor

That's why I contracted one impl to one line, but left the other impl as three lines in the update.

@vi

vi Oct 2, 2017

Contributor

That's why I contracted one impl to one line, but left the other impl as three lines in the update.

rustdoc: Remove cruft from the test
per @GuillaumeGomez's sample, but with one change.
@vi

This comment has been minimized.

Show comment
Hide comment
@vi

vi Oct 2, 2017

Contributor

@GuillaumeGomez, Done, but one impl is intentionally left as 3 lines instead of just {}.

Contributor

vi commented Oct 2, 2017

@GuillaumeGomez, Done, but one impl is intentionally left as 3 lines instead of just {}.

@GuillaumeGomez

This comment has been minimized.

Show comment
Hide comment
@GuillaumeGomez

GuillaumeGomez Oct 3, 2017

Member

Ok, then it's all good now. Thanks!

@bors: r+ rollup

Member

GuillaumeGomez commented Oct 3, 2017

Ok, then it's all good now. Thanks!

@bors: r+ rollup

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Oct 3, 2017

Contributor

📌 Commit acef039 has been approved by GuillaumeGomez

Contributor

bors commented Oct 3, 2017

📌 Commit acef039 has been approved by GuillaumeGomez

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Oct 3, 2017

Contributor

⌛️ Testing commit acef039 with merge 61bad30...

Contributor

bors commented Oct 3, 2017

⌛️ Testing commit acef039 with merge 61bad30...

bors added a commit that referenced this pull request Oct 3, 2017

Auto merge of #44920 - vi:rustdoc_implementors_src_link, r=GuillaumeG…
…omez

 rustdoc: Render [src] links for trait implementors

Should close #43893.

<s>No tests [yet].</s>

r? @QuietMisdreavus
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Oct 3, 2017

Contributor

☀️ Test successful - status-appveyor, status-travis
Approved by: GuillaumeGomez
Pushing 61bad30 to master...

Contributor

bors commented Oct 3, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: GuillaumeGomez
Pushing 61bad30 to master...

@bors bors merged commit acef039 into rust-lang:master Oct 3, 2017

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment