-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Fix spacing of links in inline code. #88343
Conversation
This comment has been minimized.
This comment has been minimized.
TIL, |
Should hopefully pass CI now |
Seems fine in principle but I haven't read the diff, I'll try to get to it this weekend. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looked at the first couple commits and they seem fine, but there's a lot of churn adding tooltips and I'm not really sure why they're useful to add - would like to hear more about that before spending more time on review.
//! [`format!`]: crate::format | ||
//! [`to_string`]: crate::string::ToString | ||
//! [`writeln!`]: core::writeln | ||
//! [`fmt::Result`]: Result "fmt::Result" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By default this won't have a tooltip, right? Why did you add one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, links generated by rustdoc do have a tooltip.
E.g. something like
/// Talking about [`Result`][std::fmt::Result] here!
pub mod m {}
will come with a tooltip
Whereas (unfortunately) the following alternative
/// Talking about [`Result`] here!
///
/// [`Result`]: std::fmt::Result
pub mod m {}
creates almost the same documentation, just lacking the tooltip. That’s the general reason why I’ve converted many instances of
[foo]: path
into
[foo]: path "path"
and in some cases, I’ve also adjusted the tooltip slightly to make it more easy to understand. This includes the case here because Result
is part of the prelude, a simple "Result"
tooltip seems confusing to me, the std::
prefix is something I’ve often avoided for tooltips OTOH (not least because the paths themselves also often are relative so some imported std::foo
module).
Also, as mentioned in the description of this PR, the addition of tooltips isn’t systematic and only covers places that I happened to come across. (Furthermore, the amount of tooltips added declines from earlier to later commits.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. I think this would be better to fix systematically in rustdoc rather than adding it piecemeal to individual links. Could you open an issue and revert the tooltips you've added this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"revert" as in “add another commit to revert them” or as a “rebase / edit / force push”. Because the former could easily happen in a later PR, too; these tooltips aren't particularly hard to find (and remove) with a regex search.
Either way, the revert would only remove those cases where the path and tooltip look identical, right? E.g. the fmt::Result
should better stay IMO, because I don't like a Result
tooltip.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, no answer. I’m assuming that an additional commit is okay, and that only the ones where tooltip and path are identical need to be removed. This is more easily accomplished by a systematic find-and-replace that by looking through all my commits here. This could, as noted, easily be a separate PR, done after the relevant change to rustdoc was made, but I’m including a commit here now to get this PR going.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay, I haven't had much time for rust lately.
Either way, the revert would only remove those cases where the path and tooltip look identical, right? E.g. the fmt::Result should better stay IMO, because I don't like a Result tooltip.
Well, ideally I wouldn't want any changes, because it makes them inconsistent and it will hopefully be done by rustdoc automatically eventually ... but if you feel strongly it seems fine to keep, it's just more work for me to review. I misunderstood - you're talking about showing core::result::Result
links as std::result::Result
and that sort of thing. I guess that's fine? I think showing the link used in the source is more clear in a way but I don't feel strongly.
I’m assuming that an additional commit is okay, and that only the ones where tooltip and path are identical need to be removed.
Yup, that's fine - I don't have strong opinions about git commits.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think showing the link used in the source is more clear in a way but I don't feel strongly.
The problem I see is that the link used in the source code depends on what the imports are, and the imports depends on what happens to be used in the source code. If e.g. I’m writing documentation mentioning, say, mem::transmute
, then I’d use the path men::transmute
(resulting in a men::transmute
tooltip) if the module I’m in does use core::mem
(or use crate::mem
). But if mem
is only used in docs, AFAIK I can’t just add an import for that because (I think) it’ll trigger an unused imports lint and fail CI. But it’s IMO better to concistently have it have the tooltip mem::transmute
and not sometimes core::mem::transmute
or and crate::mem::transmute
, etc…, depending on the implementation details (i.e. imports) of the module your documentation comes from (in particular, I don’t think the crate::
prefix is a good thing showing up in standard library tooltips).
For me it’s mostly a question of consistency. I don’t like not having a tooltip simply because of the decision to not put the link inline but separately in a links section in markdown. I don’t like reading docs where half the links give me tooltips and the other half don’t (for no apparent reason to the reader); that’s also the reason why I had systematically included tooltips in #80733. |
@rustbot label -S-waiting-on-author +S-waiting-on-review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer not to review PRs this big in the future - please wait until some of the rustdoc issues are fixed before making more PRs.
/// [`str`]: prim@str "str" | ||
/// [`&str`]: prim@str "&str" | ||
/// [Deref]: core::ops::Deref "ops::Deref" | ||
/// [`Deref`]: core::ops::Deref "ops::Deref" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: you can avoid needing a second reference link by using [`Deref`][Deref]
. But doesn't seem important to change.
@@ -476,7 +477,7 @@ impl<T> Arc<T> { | |||
/// assert_eq!(*zero, 0) | |||
/// ``` | |||
/// | |||
/// [zeroed]: ../../std/mem/union.MaybeUninit.html#method.zeroed | |||
/// [zeroed]: mem::MaybeUninit::zeroed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh, did this move into core recently or something? Or was it just missed when converting links to intra-doc links?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no idea :-)
r=me with the linkchecker passing. Not sure if you have bors privileges or not, just in case - @bors delegate=steffahn Please use |
✌️ @steffahn can now approve this pull request |
oh - and please squash the commits before merging too if you don't mind :) |
I don’t :-)
okay |
---------- Fix spacing for links inside code blocks, and improve link tooltips in alloc::fmt ---------- Fix spacing for links inside code blocks, and improve link tooltips in alloc::{rc, sync} ---------- Fix spacing for links inside code blocks, and improve link tooltips in alloc::string ---------- Fix spacing for links inside code blocks in alloc::vec ---------- Fix spacing for links inside code blocks in core::option ---------- Fix spacing for links inside code blocks, and improve a few link tooltips in core::result ---------- Fix spacing for links inside code blocks in core::{iter::{self, iterator}, stream::stream, poll} ---------- Fix spacing for links inside code blocks, and improve a few link tooltips in std::{fs, path} ---------- Fix spacing for links inside code blocks in std::{collections, time} ---------- Fix spacing for links inside code blocks in and make formatting of `&str`-like types consistent in std::ffi::{c_str, os_str} ---------- Fix spacing for links inside code blocks, and improve link tooltips in std::ffi ---------- Fix spacing for links inside code blocks, and improve a few link tooltips in std::{io::{self, buffered::{bufreader, bufwriter}, cursor, util}, net::{self, addr}} ---------- Fix typo in link to `into` for `OsString` docs ---------- Remove tooltips that will probably become redundant in the future ---------- Apply suggestions from code review Replacing `…std/primitive.reference.html` paths with just `reference` Co-authored-by: Joshua Nelson <[email protected]> ---------- Also replace `…std/primitive.reference.html` paths with just `reference` in `core::pin`
0cd3835
to
67065fe
Compare
Squashed (no changes) @bors r=jyn514 |
📌 Commit 67065fe has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (addb4da): comparison url. Summary: This change led to large relevant regressions 😿 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression |
This “regression” is about how fast rustc compiles some specific crate, right? (I have no idea where to find more information about those test cases.) This PR only changes (doc) comments in the standard library, so the regression is either sporadic or very weird. If it's a sporadic thing, the benchmark of the next PR that gets merged by bors should perform better again; we'll see. |
An update: Turns out this was a "very weird" regression. Thanks to great investigation by @Mark-Simulacrum, we've identified a possible cause for this which should be fixed by #89408. I'm going to mark this as triaged. @rustbot label +perf-regression-triaged @steffahn just as an FYI, you can find more info on perf testing here. |
Similar to #80733, but the focus is different. This PR eliminates all occurrences of pieced-together inline code blocks like
Box
<
Option
<T>>
and replaces them with good-looking ones (using HTML-syntax), likeBox<Option<T>>
. As far as I can tell, I should’ve found all of these in the standard library (regex search withr"`\]`|`\[`"
) [except for incore::convert
where I’ve noticed other things in the docs that I want to fix in a separate PR]. In particular, unlike #80733, I’ve added almost no new instance of inline code that’s broken up into multiple links (or some link and some link-free part). I also added tooltips (the stuff in quotes for the markdown link listings) in places that caught my eye, but that’s by no means systematic, just opportunistic.Context: I got annoyed by repeatedly running into new misformatted inline code while reading the standard library docs. I know that once issue #83997 (and/or related ones) are resolved, these changes become somewhat obsolete, but I fail to notice much progress on that end right now.
r? @jyn514