-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Use relative path for local links to primitives #74077
Use relative path for local links to primitives #74077
Conversation
Else, links to `char::foo` would point into `/path/to/src/libcore/std/primitive.char.html#method.foo`. Split out from rust-lang#73804.
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ollie27 (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. |
cc @jyn514 |
Note that this is not special to Please add some test cases in |
Ah, gotcha, thanks for the pointers. I'm still in the "using words that I've seen once or twice in totally wrong ways" phase of learning! I'll take a look into adding a test. A question I had about this is whether it'll break in a non-rustc context – for example, would someone try to link to |
Ah hmm good point. With that in mind I don't think this is the right solution - note it appends I think this is actually a bug in x.py itself:
Note that cc @Mark-Simulacrum @GuillaumeGomez , am I missing something? |
Not sure what the right value is, not knowing what the flag does -- I can't imagine it making a difference whether we point to the build directory or source, though, seeing as neither will be in the same place when the documentation is read in the web browser. But maybe I'm misinterpreting? I don't really know. It's been like that since fb2813b -- this seems to be the relevant line: Line 362 in 0cd7ff7
|
Ah yeah you're right, |
@sethp do you mind if I take over this fix? It's not clear to me what/where the bug is so someone is going have to spend a fair bit of time debugging. |
I think that would be fine: I've spent a fair bit of time adding log statements already and not getting very far 😆 I will say – the more I look at this, the more I suspect it is a valid fix, because I'm not sure what other context would produce a rust/src/librustdoc/html/render/cache.rs Lines 509 to 513 in 2753fab
I think I read that as "we're local just in case there's a directory for it in the output path we're emitting to," which seems like exactly the right time to be giving a relative link like this? I haven't come up with a test case yet, everything I try generating docs for |
Ah hmm interesting. I'm not super familiar with this part of the codebase, if you think it's the right approach let's |
Looks good to me as well but please add a test. |
It's a reasonable request that I'm not quite sure how to honor – in the few hours I've spent trying to activate that code path, the only time I can successfully hit it is when documenting I'd be glad for some guidance on how to test this case. Ultimately the point of all of this is to remove the exclusion for broken links in the standard library's String pages, which will indirectly check this code path, but not in a very obvious way. |
In this case, the best would be to add a check on the generated HTML so take a look at |
@GuillaumeGomez their point is that this doesn't happen in stand alone cases, only when documenting core. So they can't test it in src/test/rustdoc. @sethp - have you tried defining |
I don't think this is the right approach, it breaks docs for any crate that uses |
Oh, interesting – perhaps this is the test case I should try to add? Is that what |
Yes, exactly. I'd be interested if that reproduces the bug. |
They both produce less-than-desirable output (links going to docs.rust-lang.org), but I haven't figured out yet how to assert about them properly.
Well, not quite. 33a5d00 does show us two new behaviors when I run it: both end up linking out to Some questions I have to look into tomorrow:
|
Yes, look for
Good question, I'm not sure. I'd be interested what happens after the change I suggest below though.
Isn't this because you special case |
Ah, thank you, I will take a look at that!
I thought so too, but even after reverting ee3a0f8 I see the same behavior. With a little bit of print-based debugging what I've found is that the
But the
However, in that case we only ever seem to pass in a I'm not too sure what any of that means, yet. I am starting to wonder if it wouldn't make sense to consider the |
For the auxiliary case, try also adding Does the same issue show up when you have a Lang item in the crate being documented? That's surprising to me. |
Same! Neither of the two tests I added are doing what I expected:
However, both complain when I omit the |
For the two of these tests that have a local `char` to link to, this behavior isn't what's expected, but is what's happening presently.
bors r- |
There don't seem to be any other compiletests that are 1) building a standalone "no_core" create and then 2) trying to link against it. There seems to be a platform-specific limitation in doing so: ``` 2020-07-08T16:07:42.9419409Z = note: Creating library D:\a\rust\rust\build\i686-pc-windows-msvc\test\rustdoc\intra-link-prim-methods-external-core\auxiliary\my_core.dll.lib and object D:\a\rust\rust\build\i686-pc-windows-msvc\test\rustdoc\intra-link-prim-methods-external-core\auxiliary\my_core.dll.exp 2020-07-08T16:07:42.9419810Z LINK : error LNK2001: unresolved external symbol __DllMainCRTStartup@12 2020-07-08T16:07:42.9420032Z D:\a\rust\rust\build\i686-pc-windows-msvc\test\rustdoc\intra-link-prim-methods-external-core\auxiliary\my_core.dll : fatal error LNK1120: 1 unresolved externals ``` Possibly this could be resolved by adding a `__DllMainCRTStartup` or `__DllMainCRTStartup@12` symbol in an architecture- and platform-specific way.
I don't think I have access to a Windows system to test on, but there seems to be a few other @Manishearth would you be willing to try again? |
@bors r=jyn514 |
📌 Commit 56b6b44 has been approved by |
…link, r=jyn514 Use relative path for local links to primitives Else, links to `char::foo` would point into `/path/to/src/libcore/std/primitive.char.html#method.foo`. Split out from rust-lang#73804.
…link, r=jyn514 Use relative path for local links to primitives Else, links to `char::foo` would point into `/path/to/src/libcore/std/primitive.char.html#method.foo`. Split out from rust-lang#73804.
…arth Rollup of 14 pull requests Successful merges: - rust-lang#73292 (Fixing broken link for the Eq trait) - rust-lang#73791 (Allow for parentheses after macro intra-doc-links) - rust-lang#74070 ( Use for<'tcx> fn pointers in Providers, instead of having Providers<'tcx>.) - rust-lang#74077 (Use relative path for local links to primitives) - rust-lang#74079 (Eliminate confusing "globals" terminology.) - rust-lang#74107 (Hide `&mut self` methods from Deref in sidebar if there are no `DerefMut` impl for the type.) - rust-lang#74136 (Fix broken link in rustdocdoc) - rust-lang#74137 (Update cargo) - rust-lang#74142 (Liballoc use vec instead of vector) - rust-lang#74143 (Try remove unneeded ToString import in liballoc slice) - rust-lang#74146 (update miri) - rust-lang#74150 (Avoid "blacklist") - rust-lang#74184 (Add docs for intra-doc-links) - rust-lang#74188 (Tweak `::` -> `:` typo heuristic and reduce verbosity) Failed merges: - rust-lang#74122 (Start-up clean-up) - rust-lang#74127 (Avoid "whitelist") r? @ghost
@sethp I finally figured out why you couldn't reproduce the issue: #73423 (comment) |
Oh, interesting – it looks like that's definitely part of it. With a diff --git a/src/test/rustdoc/auxiliary/my-core.rs b/src/test/rustdoc/auxiliary/my-core.rs
index 54e986be9ec..208e9ca26f4 100644
--- a/src/test/rustdoc/auxiliary/my-core.rs
+++ b/src/test/rustdoc/auxiliary/my-core.rs
@@ -17,3 +17,8 @@ pub trait Clone: Sized {}
#[lang = "copy"]
pub trait Copy: Clone {}
+
+
+#[doc(primitive = "char")]
+/// Docs for the primitive char type
+mod prim_char {} I do see that Unfortunately, it still generates links to nightly. I think the other detail here is that the |
Try it within a single crate instead of across crates? Or rebase over master now that #73101 is merged? |
Else, links to
char::foo
would point into/path/to/src/libcore/std/primitive.char.html#method.foo
.Split out from #73804.