-
Notifications
You must be signed in to change notification settings - Fork 13.3k
rustdoc: Remove GetDefId
#90154
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: Remove GetDefId
#90154
Conversation
Based on looking at the source code, it looks like the `did` needs to be for an impl, not functions in an impl.
This comment has been minimized.
This comment has been minimized.
3c270b9
to
55838a4
Compare
This comment has been minimized.
This comment has been minimized.
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.
👍 making this not a trait is an excellent idea, thanks for spotting this :)
src/librustdoc/clean/inline.rs
Outdated
@@ -374,7 +374,7 @@ crate fn build_impl( | |||
// Only inline impl if the implementing type is | |||
// reachable in rustdoc generated documentation | |||
if !did.is_local() { | |||
if let Some(did) = for_.def_id() { | |||
if let Some(did) = for_.def_id_full(&cx.cache) { |
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 something in this commit broke the linkchecker, not sure exactly which change. Maybe try reverting them one at a time until you find what went wrong? If you could write a test for it that would be amazing ❤️ but I won't block on that.
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.
Haha, this is so great. My commit "broke" the linkchecker — because some impls that should have been shown on str
's page were not because def_id_full
was not being used, and they have stuff like this, which are interpreted as links by the linkchecker:
I'll update those docs to use inline code. EDIT: Instead, I just escaped the brackets.
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.
Should be fixed now :)
It was only used in one place, so it seems better to use ordinary functions.
Now that it's only implemented for `Type`, using inherent methods instead means that imports are no longer necessary. Also, `GetDefId` is only meant to be used with `Type`, so it shouldn't be a trait.
In general, it should be preferred over `Type::def_id()`. See each method's docs for more.
The old name was confusing because it's easy to assume that using `def_id()` is fine, but in some situations it's incorrect. In general, `def_id_full()` should be preferred, so `def_id_full()` should have a shorter name. That will happen in the next commit.
It should be preferred over `def_id_no_primitives()`, so it should have a shorter name. I also put it before `def_id_no_primitives()` so that it shows up first in the docs.
8c6f07a
to
f801ac3
Compare
Hmm, I guess the linkchecker really doesn't like seeing brackets in the HTML. Why does it even check for broken intra-doc links; doesn't rustdoc do that? |
I'll just add to the exceptions list for now since there are almost identical exceptions there already. |
My change to use `Type::def_id()` (formerly `Type::def_id_full()`) in more places caused some docs to show up that used to be missed by rustdoc. Those docs contained unescaped square brackets, which triggered linkcheck errors. This commit escapes the square brackets and adds this particular instance to the linkcheck exception list.
f801ac3
to
865d99f
Compare
Rustdoc has been buggy in the past, this helped catch quite a lot of links when it was introduced. I don't have a link to the PR offhand. |
@@ -234,7 +234,7 @@ unsafe impl SliceIndex<str> for ops::Range<usize> { | |||
/// Implements substring slicing with syntax `&self[.. end]` or `&mut | |||
/// self[.. end]`. | |||
/// | |||
/// Returns a slice of the given string from the byte range [`0`, `end`). | |||
/// Returns a slice of the given string from the byte range \[0, `end`). |
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.
Maybe instead just surround the whole range with backticks? That seems like it would look nicer when displayed too.
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 initially was going to do that, but then I realized that closed ranges might look like arrays instead, which could be confusing: [0, end]
. I was also leaning on the side of having the docs be displayed the same way as before. In addition, based on the pre-existing link-check exceptions, it seems that the [0, end
] style is the "standard" way to write it.
All that said, I'm fine either way, so I can change them if you would prefer.
@bors r+ |
📌 Commit 3ad0834 has been approved by |
…askrgr Rollup of 3 pull requests Successful merges: - rust-lang#90154 (rustdoc: Remove `GetDefId`) - rust-lang#90232 (rustdoc: Use TTF based font instead of OTF for CJK glyphs to improve readability) - rust-lang#90278 (rustdoc: use better highlighting for *const, *mut, and &mut) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
See the individual commit messages for details.
r? @jyn514