Add rustdoc version into the help popup

[GuillaumeGomez]

After a discussion with a rustdoc user about a specific behaviour, we realized we were not talking about the same version. To add on top of it, it was actually not that simple to find out the version since it was hosted documentation.

So to simplify things, I added the version into the help popup:

Does the version format looks or would you prefer that I add more information? We can also add the commit hash, commit date, host and release.

cc @rust-lang/rustdoc
r? @jyn514

[rust-highfive]

Some changes occurred in HTML/CSS/JS.

cc @GuillaumeGomez

[Nemo157]

I feel like the full short-form like the CLI would be enough (rustdoc 1.53.0 (53cb7b09b 2021-06-17)), host shouldn't affect the output.

[GuillaumeGomez]

So commit hash and commit date as well, sounds good to me!

[GuillaumeGomez]

Actually, they're already supposed to be in. Funny:

$ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustdoc -V
rustdoc 1.57.0-dev
$ rustdoc -V
rustdoc 1.56.0-nightly (af140757b 2021-08-22)

[jyn514]

r? @Nemo157

[camelid]

(Weird, I didn't see the @rust-lang/rustdoc ping... GitHub notifications have been acting up for me recently.)

I like this change a lot; there have been many times in the past that I've wanted to know what rustdoc version some docs were generated with. However, I'm wondering whether the help popup is the best place to put it. It seems fine to put it there for now, but I wanted to bring up the topic.

Does the version format looks or would you prefer that I add more information? We can also add the commit hash, commit date, host and release.

I agree with Nemo that having the regular rustdoc --version output would be good. I also have a styling comment: I feel like it would be better to have it with inline code style.

[GuillaumeGomez]

I agree with Nemo that having the regular rustdoc --version output would be good. I also have a styling comment: I feel like it would be better to have it with inline code style.

I use exactly the same function used for the -V option. It's that apparently, the two missing parameters (commit hash and date) are not passed for the dev, only for a "release" (including all nightly versions). Take a look at my explanations just above.

I like this change a lot; there have been many times in the past that I've wanted to know what rustdoc version some docs were generated with. However, I'm wondering whether the help popup is the best place to put it. It seems fine to put it there for now, but I wanted to bring up the topic.

I actually see a few advantages to this:

• It doesn't take more space that needed (the JS file is generated once, allowing to have this information to not be duplicated into few places).
• It's easy to tell to people where to look in case we need this information.

But if you have suggestion for another place, I'm all for it. My second choice was on the crate page (but not sure where to put it though), my third one was in the setting page (but don't like this one much...).

[camelid]

• the JS file is generated once, allowing to have this information duplicated into few places

Does that mean that if different crates in the docs were built with different rustdoc versions, it would only show one of the versions? It seems like we should make sure it shows the version used to build the crate the user is looking it, to avoid any possibility for confusion.

[jyn514]

FWIW, the version thing shouldn't affect docs.rs, since it uses a --resource-suffix that includes the version. But I suppose it could make a difference when documenting locally.

[jyn514]

Actually, cargo since recently deletes files in doc/ when rerunning rustdoc, so it shouldn't make a difference even locally.

[GuillaumeGomez]

Does that mean that if different crates in the docs were built with different rustdoc versions, it would only show one of the versions? It seems like we should make sure it shows the version used to build the crate the user is looking it, to avoid any possibility for confusion.

It'll have the last version yes (which is why I thought about putting it into the crate doc page). But like @jyn514 said, unless you are doing something strange, it shouldn't be a concern.

[camelid]

Actually, cargo since recently deletes files in doc/ when rerunning rustdoc, so it shouldn't make a difference even locally.

Although that doesn't help for using rustdoc ... manually. But I guess it'd be pretty rare to have putting it in the help popup cause an issue so it seems fine.

[Nemo157]

I feel like it would be better to have it with inline code style.

I also agree with this.

[GuillaumeGomez]

Done! (updated the screenshot as well)

[Nemo157]

Sounds like we're happy with the slight chance for inconsistency on manual cross-version rustdoc usage.

@bors r+

[bors]

📌 Commit 26eb5bb has been approved by Nemo157

[bors]

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

[GuillaumeGomez]

@bors: r=Nemo157

[bors]

📌 Commit cd3f4da has been approved by Nemo157