Skip to content
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: redirect URLs #35236

Merged
merged 4 commits into from
Aug 17, 2016
Merged

rustdoc: redirect URLs #35236

merged 4 commits into from
Aug 17, 2016

Conversation

nrc
Copy link
Member

@nrc nrc commented Aug 3, 2016

cc #35020 which does this properly

r? @alexcrichton

@nrc nrc added the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label Aug 3, 2016
@nrc nrc mentioned this pull request Aug 3, 2016
@nrc
Copy link
Member Author

nrc commented Aug 3, 2016

cc @steveklabnik, @ollie27

@alexcrichton
Copy link
Member

@nrc so just to clarify, this emits Foo.v.html which redirects to struct.Foo.html?

@ollie27
Copy link
Member

ollie27 commented Aug 4, 2016

As with the previous PR, methods and struct fields are in the same namespace so we get conflicts. For example std::ops::Range has two start.v ids. Is that not a problem?

@nrc
Copy link
Member Author

nrc commented Aug 4, 2016

As with the previous PR, methods and struct fields are in the same namespace so we get conflicts. For example std::ops::Range has two start.v ids. Is that not a problem?

It is, but without changing the canonical URLs/anchors there doesn't seem to be a great way to disambiguate. However, since these are not canonical URLs, it doesn't really matter - for tool users who link to Rustdoc, there will be a very few URLs that don't work properly, but I expect this to be a pretty small edge case.

@nrc
Copy link
Member Author

nrc commented Aug 4, 2016

so just to clarify, this emits Foo.v.html which redirects to struct.Foo.html?

Well, Foo.t.html, but yes that is basically what is happening here, plus the extra anchors for 'sub-items'.

@alexcrichton
Copy link
Member

@bors: r+ 525b77e

@ollie27
Copy link
Member

ollie27 commented Aug 8, 2016

There are a few issues with the implementation:

  • Nested <a> tags are invalid so you'll need to use another tag for the new ids.
  • ids are supposed to be unique so you'll need to call derive_id for all the new ones.
  • There should probably be a few new tests 😉.

@alexcrichton
Copy link
Member

@bors: r-, ah, good points!

@bors
Copy link
Contributor

bors commented Aug 9, 2016

⌛ Testing commit 525b77e with merge 8d86593...

@alexcrichton
Copy link
Member

@bors: r-

er... maybe a mis-parse?

@bors
Copy link
Contributor

bors commented Aug 9, 2016

💔 Test failed - auto-win-msvc-64-opt-rustbuild

@nrc
Copy link
Member Author

nrc commented Aug 9, 2016

bors is clearly hungry for this PR, it won't take 'no' for an answer

@nrc
Copy link
Member Author

nrc commented Aug 11, 2016

re tests, does anyone (@ollie27?) have suggestions for how to test the existence of the redirects? I don't see a way to fit it into the existing framework, but I don't know it very well.

@alexcrichton
Copy link
Member

I think you can at least test for their existence with the rustdoc tests, and maybe html tags inside them as well?

@ollie27
Copy link
Member

ollie27 commented Aug 14, 2016

Check out test/rustdoc/redirect.rs and test/rustdoc/issue-33302.rs for examples which test the same kind of things.

For example I'd do something like the following for structs:

#![crate_name = "foo"]

// @has 'foo/FooStruct.t.html'
// @has - '//p/a' 'struct.FooStruct.html'
// @has 'foo/struct.FooStruct.html'
pub struct FooStruct {
    // @has - '//*[@id="foo.v"]' 'foo'
    pub foo: (),
    // @has - '//*[@id="dupe.v"]' 'dupe'
    pub dupe: (),
}
impl FooStruct {
    // @has - '//*[@id="bar.v"]' 'bar'
    pub fn bar() {}
    // @has - '//*[@id="dupe.v-1"]' 'dupe'
    pub fn dupe() {}
}

You should be able repeat that for every other item type.

@nrc
Copy link
Member Author

nrc commented Aug 14, 2016

@ollie27 I tried something like this and it doesn't work. I'm not really clear on the semantics of @has, but I'm assuming it is ensuring that the text string occurs in the generated document. So, your example is saying that there should be a link to each of struct.FooStruct.html and FooStruct.t.html, which there isn't - there is only a link to the former. Is my understanding correct? Is there a way to check for the existence of a file?

@ollie27
Copy link
Member

ollie27 commented Aug 15, 2016

Check out src/etc/htmldocck.py for a better explanation than I could give.

@nrc
Copy link
Member Author

nrc commented Aug 15, 2016

Thanks for the link, I knew these must be documented somewhere.

PATH is relative to the output directory. It can be given as - which repeats the most recently used PATH.

This is what was tripping me up.

@nrc
Copy link
Member Author

nrc commented Aug 15, 2016

Updated with tests, spans instead of anchors, and unique ids.

@alexcrichton r?

@alexcrichton
Copy link
Member

@bors: r+ 6765f7e

@bors
Copy link
Contributor

bors commented Aug 16, 2016

⌛ Testing commit 6765f7e with merge 30adf96...

@bors
Copy link
Contributor

bors commented Aug 16, 2016

💔 Test failed - auto-win-gnu-32-opt-rustbuild

</span><span class='stab {stab}'></span>",
shortty = ItemType::StructField,
write!(w, "<span id='{item_type}.{name}' class='{item_type}'>
<span id='{name}.{name_space}' class='invisible'>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You'll need to use derive_id for these as well. The existing ids are also missing a call to derive_id so you may as well also fix that while you're at it.

@@ -2366,9 +2389,12 @@ fn item_enum(w: &mut fmt::Formatter, cx: &Context, it: &clean::Item,
if let StructFieldItem(ref ty) = field.inner {
write!(w, "<tr><td \
id='variant.{v}.field.{f}'>\
<code>{f}:&nbsp;{t}</code></td><td>",
<span id='{v}.{vns}.{f}.{fns}' class='invisible'>\
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here.

@ollie27
Copy link
Member

ollie27 commented Aug 16, 2016

I was hoping you'd add a new test covering every single item type. For example enum variant struct fields and macros are different so need explicit tests.

Are you going to document this feature anywhere? What kind of stability guarantees do these new URLs have? Can other people use them?

@nrc
Copy link
Member Author

nrc commented Aug 16, 2016

I was hoping you'd add a new test covering every single item type. For example enum variant struct fields and macros are different so need explicit tests.

I suppose a few more tests couldn't hurt. The main code paths are exercised and the coverage seems as good or better than existing Rustdoc tests.

Are you going to document this feature anywhere?

No. I see no point in encouraging use of these until the long-term URL solution is figured out.

What kind of stability guarantees do these new URLs have?

None, use at your own risk.

Can other people use them?

Sure, but I wouldn't encourage it.

You'll need to use derive_id for these as well. The existing ids are also missing a call to derive_id so you may as well also fix that while you're at it.

I was assuming there was some logic behind not calling derive_id here (e.g., you can't have duplicate named fields, so I assume there can't be a name clash).

@ollie27
Copy link
Member

ollie27 commented Aug 16, 2016

The main code paths are exercised and the coverage seems as good or better than existing Rustdoc tests.

The test coverage in rustdoc isn't very good right now so we should be aiming for better coverage.

I was assuming there was some logic behind not calling derive_id here (e.g., you can't have duplicate named fields, so I assume there can't be a name clash).

derive_id is also used by the markdown so I was worried it might conflict there but having a closer look, it turns out the markdown will never create an id containing a . so technically they can't conflict. It wouldn't harm to call derive_id though, we definitely need to call it for the new ones anyway.

@nrc
Copy link
Member Author

nrc commented Aug 17, 2016

@bors r=@alexcrichton

@bors
Copy link
Contributor

bors commented Aug 17, 2016

📌 Commit 879637f has been approved by @alexcrichton

@bors
Copy link
Contributor

bors commented Aug 17, 2016

⌛ Testing commit 879637f with merge 6c0d66a...

bors added a commit that referenced this pull request Aug 17, 2016
rustdoc: redirect URLs

cc #35020 which does this properly

r? @alexcrichton
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants