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

show in docs whether the return type of a function impls Iterator/Read/Write #45039

Merged
merged 7 commits into from Nov 21, 2017

Conversation

Projects
None yet
7 participants
@QuietMisdreavus
Member

QuietMisdreavus commented Oct 5, 2017

Closes #25928

This PR makes it so that when rustdoc documents a function, it checks the return type to see whether it implements a handful of specific traits. If so, it will print the impl and any associated types. Rather than doing this via a whitelist within rustdoc, i chose to do this by a new #[doc] attribute parameter, so things like Future could tap into this if desired.

Known shortcomings

The printing of impls currently uses the where class over the whole thing to shrink the font size relative to the function definition itself. Naturally, when the impl has a where clause of its own, it gets shrunken even further: (This is no longer a problem because the design changed and rendered this concern moot.)

The lookup currently just looks at the top-level type, not looking inside things like Result or Option, which renders the spotlights on Read/Write a little less useful:

`File::{open, create}` don't have spotlight info (pic of old design)

image

All three of the initially spotlighted traits are generically implemented on &mut references. Rustdoc currently treats a &mut T reference-to-a-generic as an impl on the reference primitive itself. &mut Self counts as a generic in the eyes of rustdoc. All this combines to create this lovely scene on Iterator::by_ref:

`Iterator::by_ref` spotlights Iterator, Read, and Write (pic of old design)

image

@rust-highfive

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Oct 5, 2017

Collaborator

Some changes occurred in HTML/CSS.

cc @GuillaumeGomez

Collaborator

rust-highfive commented Oct 5, 2017

Some changes occurred in HTML/CSS.

cc @GuillaumeGomez

@rust-highfive

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Oct 5, 2017

Collaborator

r? @GuillaumeGomez

(rust_highfive has picked a reviewer for you, use r? to override)

Collaborator

rust-highfive commented Oct 5, 2017

r? @GuillaumeGomez

(rust_highfive has picked a reviewer for you, use r? to override)

@QuietMisdreavus

This comment has been minimized.

Show comment
Hide comment
@QuietMisdreavus

QuietMisdreavus Oct 5, 2017

Member

@rust-lang/docs Bikeshed request: Is this layout okay? Also which of the "Known shortcomings" above should i work to resolve before merging this, and which are okay to keep around while the spotlight parameter is still unstable?

Member

QuietMisdreavus commented Oct 5, 2017

@rust-lang/docs Bikeshed request: Is this layout okay? Also which of the "Known shortcomings" above should i work to resolve before merging this, and which are okay to keep around while the spotlight parameter is still unstable?

@GuillaumeGomez

This comment has been minimized.

Show comment
Hide comment
@GuillaumeGomez

GuillaumeGomez Oct 5, 2017

Member

I don't like it. It feels like the function is implementing all this. We should try to think about how to give this information but not by default (the display is already very heavy). Maybe when we hover a little symbol close to the returned type? Or maybe even when hovering the returned type directly?

Member

GuillaumeGomez commented Oct 5, 2017

I don't like it. It feels like the function is implementing all this. We should try to think about how to give this information but not by default (the display is already very heavy). Maybe when we hover a little symbol close to the returned type? Or maybe even when hovering the returned type directly?

@QuietMisdreavus

This comment has been minimized.

Show comment
Hide comment
@QuietMisdreavus

QuietMisdreavus Oct 5, 2017

Member

If it's a matter of the layout on the final page, that can easily be changed. The problem with making it a hover on the return type directly is that it's not very discoverable. It's already a bit of a secret that those type names are links, so it feels like adding something that's not visible or easily explained would render this change much less useful. Making it a new icon (and putting the impl in a hover off that) at least provides some affordance, but risks being easily overlooked.

There is some precedent here with the "warning" icon on unsafe functions, and now the extra CSS on ignored doc blocks. I'm not too familiar with how something like that would be implemented, if we want the links in this impl to be clickable? Maybe putting it in a separate docblock that's automatically hidden? That may create some strange interactions with the toggle wrapper, but saves on a bit of the noise you're talking about.

(EDIT: Also i force-pushed to fix the test that broke travis.)

Member

QuietMisdreavus commented Oct 5, 2017

If it's a matter of the layout on the final page, that can easily be changed. The problem with making it a hover on the return type directly is that it's not very discoverable. It's already a bit of a secret that those type names are links, so it feels like adding something that's not visible or easily explained would render this change much less useful. Making it a new icon (and putting the impl in a hover off that) at least provides some affordance, but risks being easily overlooked.

There is some precedent here with the "warning" icon on unsafe functions, and now the extra CSS on ignored doc blocks. I'm not too familiar with how something like that would be implemented, if we want the links in this impl to be clickable? Maybe putting it in a separate docblock that's automatically hidden? That may create some strange interactions with the toggle wrapper, but saves on a bit of the noise you're talking about.

(EDIT: Also i force-pushed to fix the test that broke travis.)

@QuietMisdreavus

This comment has been minimized.

Show comment
Hide comment
@QuietMisdreavus

QuietMisdreavus Oct 5, 2017

Member

New travis error: Turns out i was generating links wrong and created a lot of broken links. I think i have a fix, but i'm running linkchecker locally to make sure i solved it.

Member

QuietMisdreavus commented Oct 5, 2017

New travis error: Turns out i was generating links wrong and created a lot of broken links. I think i have a fix, but i'm running linkchecker locally to make sure i solved it.

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Oct 5, 2017

Contributor

☔️ The latest upstream changes (presumably #45046) made this pull request unmergeable. Please resolve the merge conflicts.

Contributor

bors commented Oct 5, 2017

☔️ The latest upstream changes (presumably #45046) made this pull request unmergeable. Please resolve the merge conflicts.

@QuietMisdreavus

This comment has been minimized.

Show comment
Hide comment
@QuietMisdreavus

QuietMisdreavus Oct 5, 2017

Member

Force-pushed to resolve linkchecker and the merge conflict.

Member

QuietMisdreavus commented Oct 5, 2017

Force-pushed to resolve linkchecker and the merge conflict.

@QuietMisdreavus

This comment has been minimized.

Show comment
Hide comment
@QuietMisdreavus

QuietMisdreavus Oct 10, 2017

Member

I tried to put the trait impls into an auto-hide docblock, but i think the js that creates the toggle-wrapper got confused by something in this setup, since it didn't work:

image

What does everyone think about that "Important traits for Filter" heading? Would that help solve some of the ambiguity?

Member

QuietMisdreavus commented Oct 10, 2017

I tried to put the trait impls into an auto-hide docblock, but i think the js that creates the toggle-wrapper got confused by something in this setup, since it didn't work:

image

What does everyone think about that "Important traits for Filter" heading? Would that help solve some of the ambiguity?

@GuillaumeGomez

This comment has been minimized.

Show comment
Hide comment
@GuillaumeGomez

GuillaumeGomez Oct 10, 2017

Member

I have a lot of difficulties to appreciate this PR so I think I'll just let someone else handles all this.

Member

GuillaumeGomez commented Oct 10, 2017

I have a lot of difficulties to appreciate this PR so I think I'll just let someone else handles all this.

@carols10cents

This comment has been minimized.

Show comment
Hide comment
@carols10cents

carols10cents Oct 16, 2017

Member

Sounds like this pr is waiting for some feedback from @rust-lang/docs members? I'm going to change this to S-waiting-for-team, please adjust if that's not where this is at!

Member

carols10cents commented Oct 16, 2017

Sounds like this pr is waiting for some feedback from @rust-lang/docs members? I'm going to change this to S-waiting-for-team, please adjust if that's not where this is at!

@QuietMisdreavus

This comment has been minimized.

Show comment
Hide comment
@QuietMisdreavus

QuietMisdreavus Oct 21, 2017

Member

We did talk about this in the docs team meeting last week, and it seemed like everyone would be better on board with this if the way it was laid out on the page was cleaned up some. I need to dig into the "toggle wrapper" logic in the rustdoc javascript to see if i can get my last screenshot to work the way i wanted, where it was foldable and automatically hidden. Haven't taken the chance to do that, though.

Member

QuietMisdreavus commented Oct 21, 2017

We did talk about this in the docs team meeting last week, and it seemed like everyone would be better on board with this if the way it was laid out on the page was cleaned up some. I need to dig into the "toggle wrapper" logic in the rustdoc javascript to see if i can get my last screenshot to work the way i wanted, where it was foldable and automatically hidden. Haven't taken the chance to do that, though.

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Oct 27, 2017

Contributor

☔️ The latest upstream changes (presumably #45285) made this pull request unmergeable. Please resolve the merge conflicts.

Contributor

bors commented Oct 27, 2017

☔️ The latest upstream changes (presumably #45285) made this pull request unmergeable. Please resolve the merge conflicts.

@carols10cents

This comment has been minimized.

Show comment
Hide comment
@carols10cents

carols10cents Nov 6, 2017

Member

ping @QuietMisdreavus, looks like there are some merge conflicts in addition to the changes you wanted to make!

Member

carols10cents commented Nov 6, 2017

ping @QuietMisdreavus, looks like there are some merge conflicts in addition to the changes you wanted to make!

@QuietMisdreavus

This comment has been minimized.

Show comment
Hide comment
@QuietMisdreavus

QuietMisdreavus Nov 7, 2017

Member

I think I cracked it. The main.js was only applying toggle wrappers to .docblocks that were direct children of the main element, so my docblock-within-a-docblock wasn't working. Tweaking the wrapper code a little now makes it work, and this is how it looks now:

image

image

@rust-lang/docs What do you think about this?

Member

QuietMisdreavus commented Nov 7, 2017

I think I cracked it. The main.js was only applying toggle wrappers to .docblocks that were direct children of the main element, so my docblock-within-a-docblock wasn't working. Tweaking the wrapper code a little now makes it work, and this is how it looks now:

image

image

@rust-lang/docs What do you think about this?

@QuietMisdreavus QuietMisdreavus changed the title from [WIP] show in docs whether the return type of a function impls Iterator/Read/Write to show in docs whether the return type of a function impls Iterator/Read/Write Nov 7, 2017

@QuietMisdreavus

This comment has been minimized.

Show comment
Hide comment
@QuietMisdreavus

QuietMisdreavus Nov 7, 2017

Member

I asked @GuillaumeGomez about the latest design during today's docs team meeting, and he offered to help out with designing a better display for this, basing it on the existing modal shown for the ? menu. As long as it doesn't blur out the background like the ? menu does - it's not so important as to drown out literally everything else on the page - that could work out.

Member

QuietMisdreavus commented Nov 7, 2017

I asked @GuillaumeGomez about the latest design during today's docs team meeting, and he offered to help out with designing a better display for this, basing it on the existing modal shown for the ? menu. As long as it doesn't blur out the background like the ? menu does - it's not so important as to drown out literally everything else on the page - that could work out.

@GuillaumeGomez

This comment has been minimized.

Show comment
Hide comment
@GuillaumeGomez

GuillaumeGomez Nov 7, 2017

Member

Will write the modal code starting monday.

Member

GuillaumeGomez commented Nov 7, 2017

Will write the modal code starting monday.

@QuietMisdreavus

This comment has been minimized.

Show comment
Hide comment
@QuietMisdreavus

QuietMisdreavus Nov 16, 2017

Member

imperio and i just walked through the design of the new spotlight modal, and here's what we came up with:

Associated methods get a little circle-i next to their toggle wrapper if they return something that implements a spotlighted trait:

Example with `slice::{reverse, iter, iter_mut}`

image

Bare functions get the circle-i next to their definition:

Example with `std::iter::once`

image

Clicking the circle-i opens up a modal window that shows the impl(s) of any spotlighted traits on the return type:

"Important traits for `Once<T>`

image

The circle-i also shows up on trait pages:

Several examples from Iterator with docs collapsed

image

@GuillaumeGomez Before i start doing fine-grain code review, i have one more suggestion: Right now there's no title attribute on the circle-i. Could we put one in there, with the same text as the heading inside the modal, just so there's some more indication what it's there for, before clicking?

Member

QuietMisdreavus commented Nov 16, 2017

imperio and i just walked through the design of the new spotlight modal, and here's what we came up with:

Associated methods get a little circle-i next to their toggle wrapper if they return something that implements a spotlighted trait:

Example with `slice::{reverse, iter, iter_mut}`

image

Bare functions get the circle-i next to their definition:

Example with `std::iter::once`

image

Clicking the circle-i opens up a modal window that shows the impl(s) of any spotlighted traits on the return type:

"Important traits for `Once<T>`

image

The circle-i also shows up on trait pages:

Several examples from Iterator with docs collapsed

image

@GuillaumeGomez Before i start doing fine-grain code review, i have one more suggestion: Right now there's no title attribute on the circle-i. Could we put one in there, with the same text as the heading inside the modal, just so there's some more indication what it's there for, before clicking?

@QuietMisdreavus

This comment has been minimized.

Show comment
Hide comment
@QuietMisdreavus

QuietMisdreavus Nov 17, 2017

Member

Also, uh, it looks like htmldocck.py choked on the output? I'm not quite sure what's going on here.

[00:54:41] ---- [rustdoc] rustdoc/doc-spotlight.rs stdout ----
[00:54:41] 	
[00:54:41] error: htmldocck failed!
[00:54:41] status: exit code: 1
[00:54:41] command: "/usr/bin/python2.7" "/checkout/src/etc/htmldocck.py" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/rustdoc/doc-spotlight.stage2-x86_64-unknown-linux-gnu" "/checkout/src/test/rustdoc/doc-spotlight.rs"
[00:54:41] stdout:
[00:54:41] ------------------------------------------
[00:54:41] 
[00:54:41] ------------------------------------------
[00:54:41] stderr:
[00:54:41] ------------------------------------------
[00:54:41] Traceback (most recent call last):
[00:54:41]   File "/checkout/src/etc/htmldocck.py", line 455, in <module>
[00:54:41]     check(sys.argv[1], get_commands(sys.argv[2]))
[00:54:41]   File "/checkout/src/etc/htmldocck.py", line 448, in check
[00:54:41]     check_command(c, cache)
[00:54:41]   File "/checkout/src/etc/htmldocck.py", line 397, in check_command
[00:54:41]     tree = cache.get_tree(c.args[0])
[00:54:41]   File "/checkout/src/etc/htmldocck.py", line 309, in get_tree
[00:54:41]     raise RuntimeError('Cannot parse an HTML file {!r}: {}'.format(path, e))
[00:54:41] RuntimeError: Cannot parse an HTML file 'doc_spotlight/trait.SomeTrait.html': pop from empty stack
[00:54:41] 
[00:54:41] ------------------------------------------
Member

QuietMisdreavus commented Nov 17, 2017

Also, uh, it looks like htmldocck.py choked on the output? I'm not quite sure what's going on here.

[00:54:41] ---- [rustdoc] rustdoc/doc-spotlight.rs stdout ----
[00:54:41] 	
[00:54:41] error: htmldocck failed!
[00:54:41] status: exit code: 1
[00:54:41] command: "/usr/bin/python2.7" "/checkout/src/etc/htmldocck.py" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/rustdoc/doc-spotlight.stage2-x86_64-unknown-linux-gnu" "/checkout/src/test/rustdoc/doc-spotlight.rs"
[00:54:41] stdout:
[00:54:41] ------------------------------------------
[00:54:41] 
[00:54:41] ------------------------------------------
[00:54:41] stderr:
[00:54:41] ------------------------------------------
[00:54:41] Traceback (most recent call last):
[00:54:41]   File "/checkout/src/etc/htmldocck.py", line 455, in <module>
[00:54:41]     check(sys.argv[1], get_commands(sys.argv[2]))
[00:54:41]   File "/checkout/src/etc/htmldocck.py", line 448, in check
[00:54:41]     check_command(c, cache)
[00:54:41]   File "/checkout/src/etc/htmldocck.py", line 397, in check_command
[00:54:41]     tree = cache.get_tree(c.args[0])
[00:54:41]   File "/checkout/src/etc/htmldocck.py", line 309, in get_tree
[00:54:41]     raise RuntimeError('Cannot parse an HTML file {!r}: {}'.format(path, e))
[00:54:41] RuntimeError: Cannot parse an HTML file 'doc_spotlight/trait.SomeTrait.html': pop from empty stack
[00:54:41] 
[00:54:41] ------------------------------------------
@GuillaumeGomez

This comment has been minimized.

Show comment
Hide comment
@GuillaumeGomez

GuillaumeGomez Nov 17, 2017

Member

Maybe a missing closing tag? I'll investigate. Also, I was thinking about the title as well. Can you come up with a text to put while I work on the title design?

Member

GuillaumeGomez commented Nov 17, 2017

Maybe a missing closing tag? I'll investigate. Also, I was thinking about the title as well. Can you come up with a text to put while I work on the title design?

@QuietMisdreavus

This comment has been minimized.

Show comment
Hide comment
@QuietMisdreavus

QuietMisdreavus Nov 18, 2017

Member

image

@GuillaumeGomez I didn't want it to be a tooltip like this, i literally meant the title attribute, to use standard hover-text. Also, you didn't print the type name. I wanted "Important traits for {return type}", the exact same text as the heading. Although now that i see it, i think something like "Show important traits for {type}" may be better, since it's a link.

Also the doc-spotlight test failed:

[00:58:27] ---- [rustdoc] rustdoc/doc-spotlight.rs stdout ----
[00:58:27] 	
[00:58:27] error: htmldocck failed!
[00:58:27] status: exit code: 1
[00:58:27] command: "/usr/bin/python2.7" "/checkout/src/etc/htmldocck.py" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/rustdoc/doc-spotlight.stage2-x86_64-unknown-linux-gnu" "/checkout/src/test/rustdoc/doc-spotlight.rs"
[00:58:27] stdout:
[00:58:27] ------------------------------------------
[00:58:27] 
[00:58:27] ------------------------------------------
[00:58:27] stderr:
[00:58:27] ------------------------------------------
[00:58:27] 22: @has check failed
[00:58:27] 	`XPATH PATTERN` did not match
[00:58:27] 	    // @has - '//code[@class="spotlight"]' 'impl<T: SomeTrait> SomeTrait for Wrapper<T>'
[00:58:27] 35: @has check failed
[00:58:27] 	`XPATH PATTERN` did not match
[00:58:27] 	    // @has - '//code[@class="spotlight"]' 'impl SomeTrait for SomeStruct'
[00:58:27] 36: @has check failed
[00:58:27] 	`XPATH PATTERN` did not match
[00:58:27] 	    // @has - '//code[@class="spotlight"]' 'impl<T: SomeTrait> SomeTrait for Wrapper<T>'
[00:58:27] 43: @has check failed
[00:58:27] 	`XPATH PATTERN` did not match
[00:58:27] 	// @has - '//code[@class="spotlight"]' 'impl SomeTrait for SomeStruct'
[00:58:27] 
[00:58:27] Encountered 4 errors
Member

QuietMisdreavus commented Nov 18, 2017

image

@GuillaumeGomez I didn't want it to be a tooltip like this, i literally meant the title attribute, to use standard hover-text. Also, you didn't print the type name. I wanted "Important traits for {return type}", the exact same text as the heading. Although now that i see it, i think something like "Show important traits for {type}" may be better, since it's a link.

Also the doc-spotlight test failed:

[00:58:27] ---- [rustdoc] rustdoc/doc-spotlight.rs stdout ----
[00:58:27] 	
[00:58:27] error: htmldocck failed!
[00:58:27] status: exit code: 1
[00:58:27] command: "/usr/bin/python2.7" "/checkout/src/etc/htmldocck.py" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/rustdoc/doc-spotlight.stage2-x86_64-unknown-linux-gnu" "/checkout/src/test/rustdoc/doc-spotlight.rs"
[00:58:27] stdout:
[00:58:27] ------------------------------------------
[00:58:27] 
[00:58:27] ------------------------------------------
[00:58:27] stderr:
[00:58:27] ------------------------------------------
[00:58:27] 22: @has check failed
[00:58:27] 	`XPATH PATTERN` did not match
[00:58:27] 	    // @has - '//code[@class="spotlight"]' 'impl<T: SomeTrait> SomeTrait for Wrapper<T>'
[00:58:27] 35: @has check failed
[00:58:27] 	`XPATH PATTERN` did not match
[00:58:27] 	    // @has - '//code[@class="spotlight"]' 'impl SomeTrait for SomeStruct'
[00:58:27] 36: @has check failed
[00:58:27] 	`XPATH PATTERN` did not match
[00:58:27] 	    // @has - '//code[@class="spotlight"]' 'impl<T: SomeTrait> SomeTrait for Wrapper<T>'
[00:58:27] 43: @has check failed
[00:58:27] 	`XPATH PATTERN` did not match
[00:58:27] 	// @has - '//code[@class="spotlight"]' 'impl SomeTrait for SomeStruct'
[00:58:27] 
[00:58:27] Encountered 4 errors
@GuillaumeGomez

This comment has been minimized.

Show comment
Hide comment
@GuillaumeGomez

GuillaumeGomez Nov 18, 2017

Member

Ok, fixed the test and added the wanted thing in the tooltip.

Member

GuillaumeGomez commented Nov 18, 2017

Ok, fixed the test and added the wanted thing in the tooltip.

@QuietMisdreavus

This comment has been minimized.

Show comment
Hide comment
@QuietMisdreavus

QuietMisdreavus Nov 20, 2017

Member

Okay, so this is how it looks now:

image

I think at this point i'm ready to call it good? The tooltip having a link in there is awkward, and possibly leads to bad contrast levels depending on what font gets pulled. (On a different machine it used the sans-serif font from the headers? Not sure what's going on on this one.) If it leads to problems, the fix is literally two additional characters, so i'm not all that concerned. Here we gooooooo~

@bors r=GuillaumeGomez,QuietMisdreavus

Member

QuietMisdreavus commented Nov 20, 2017

Okay, so this is how it looks now:

image

I think at this point i'm ready to call it good? The tooltip having a link in there is awkward, and possibly leads to bad contrast levels depending on what font gets pulled. (On a different machine it used the sans-serif font from the headers? Not sure what's going on on this one.) If it leads to problems, the fix is literally two additional characters, so i'm not all that concerned. Here we gooooooo~

@bors r=GuillaumeGomez,QuietMisdreavus

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Nov 20, 2017

Contributor

📌 Commit 6047a03 has been approved by GuillaumeGomez,QuietMisdreavus

Contributor

bors commented Nov 20, 2017

📌 Commit 6047a03 has been approved by GuillaumeGomez,QuietMisdreavus

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Nov 21, 2017

Contributor

⌛️ Testing commit 6047a03 with merge 421a211...

Contributor

bors commented Nov 21, 2017

⌛️ Testing commit 6047a03 with merge 421a211...

bors added a commit that referenced this pull request Nov 21, 2017

Auto merge of #45039 - QuietMisdreavus:doc-spotlight, r=GuillaumeGome…
…z,QuietMisdreavus

show in docs whether the return type of a function impls Iterator/Read/Write

Closes #25928

This PR makes it so that when rustdoc documents a function, it checks the return type to see whether it implements a handful of specific traits. If so, it will print the impl and any associated types. Rather than doing this via a whitelist within rustdoc, i chose to do this by a new `#[doc]` attribute parameter, so things like `Future` could tap into this if desired.

### Known shortcomings

~~The printing of impls currently uses the `where` class over the whole thing to shrink the font size relative to the function definition itself. Naturally, when the impl has a where clause of its own, it gets shrunken even further:~~ (This is no longer a problem because the design changed and rendered this concern moot.)

The lookup currently just looks at the top-level type, not looking inside things like Result or Option, which renders the spotlights on Read/Write a little less useful:

<details><summary>`File::{open, create}` don't have spotlight info (pic of old design)</summary>

![image](https://user-images.githubusercontent.com/5217170/31209495-e59d027e-a950-11e7-9998-ceefceb71c07.png)

</details>

All three of the initially spotlighted traits are generically implemented on `&mut` references. Rustdoc currently treats a `&mut T` reference-to-a-generic as an impl on the reference primitive itself. `&mut Self` counts as a generic in the eyes of rustdoc. All this combines to create this lovely scene on `Iterator::by_ref`:

<details><summary>`Iterator::by_ref` spotlights Iterator, Read, and Write (pic of old design)</summary>

![image](https://user-images.githubusercontent.com/5217170/31209554-50b271ca-a951-11e7-928b-4f83416c8681.png)

</details>
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Nov 21, 2017

Contributor

☀️ Test successful - status-appveyor, status-travis
Approved by: GuillaumeGomez,QuietMisdreavus
Pushing 421a211 to master...

Contributor

bors commented Nov 21, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: GuillaumeGomez,QuietMisdreavus
Pushing 421a211 to master...

@bors bors merged commit 6047a03 into rust-lang:master Nov 21, 2017

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details

@QuietMisdreavus QuietMisdreavus deleted the QuietMisdreavus:doc-spotlight branch Feb 26, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment