The left sidebar doesn't show all the functions when using the "latest" url

[STPR]

Hello,
The left sidebar doesn't show all the functions when using the "latest" url.

For example, the following url shows the 2 functions correctly:
https://docs.rs/contour_tracing/1.0.8/contour_tracing/

While this one doesn't show the function that is part of a feature:
https://docs.rs/contour_tracing/latest/contour_tracing/

[Nemo157]

Seems to be a caching issue, https://docs.rs/contour_tracing/1.0.8/contour_tracing/sidebar-items.js has last-modified Mon, 10 Jan 2022 03:25:41 GMT while https://docs.rs/contour_tracing/latest/contour_tracing/sidebar-items.js has last-modified Tue, 03 Aug 2021 01:27:10 GMT which lines up with the last 1.0.3 build: https://docs.rs/crate/contour_tracing/1.0.3/builds.

cc @jsha, what is the caching behavior meant to be around sub-resources of latest links now?

[Nemo157]

Actually.... why does this not have the resource suffix added onto it? Even the search-index.js has that resource suffix, so I would expect every file to 🤔

[syphar]

cc @jsha, what is the caching behavior meant to be around sub-resources of latest links now?

@Nemo157 that didn't change, the PR is still open #1569

[syphar]

I can imagine it's cached separately below the separate paths,

so the reason is probably in the missing suffix?

[syphar]

@Nemo157 @GuillaumeGomez could this be a rustdoc issue?

That surfaced because we serve different versions under the same URL, while statics are always cached forever?

[GuillaumeGomez]

It's because of sidebar-items.js being different I think.

[syphar]

@GuillaumeGomez thinking about rust-lang/rust#92742 and this issue:
I believe this will only partially fix this.

I will have to think it through again, but currently I believe:

• If two crate-releases are built with different nightly compilers, the resource-suffix and the path will lead to different file-names for actually different files.
• if two crate-releases are built with the same nightly, the resource suffix will be the same, so under /latest/ there is a chance we will serve static assets from an older release.

Or am I missing something?

cc @jsha

[GuillaumeGomez]

If a crate with two different versions is built with the same compiler version, then it'll be the same issue. However, I think it'd be the same issue with search.js and search-index.js, no?

EDIT: I see there is the date followed by the compiler version. Maybe we should include the time too?

[syphar]

If a crate with two different versions is built with the same compiler version, then it'll be the same issue. However, I think it'd be the same issue with search.js and search-index.js, no?

Yep, would also be an issue for other release-assets.

EDIT: I see there is the date followed by the compiler version. Maybe we should include the time too?

Wouldn't really help. To my knowledge we don't update the compiler every night, but it's only updated on deploy

[GuillaumeGomez]

Actually, I had in mind something like this:

[compiler version]-[crate build time]

I think it would fix this issue but the question is: would it break something?

[syphar]

ah ok. My thoughts were similar, but I wanted to add create-name and version. Though this would break on rebuilds ...

I need to think it through later.

[jsha]

This category of problem is supposed to be solved by SharedResource in rustdoc's write_shared.rs:

enum SharedResource<'a> {
    /// This file will never change, no matter what toolchain is used to build it.
    ///
    /// It does not have a resource suffix.
    Unversioned { name: &'static str },
    /// This file may change depending on the toolchain.
    ///
    /// It has a resource suffix.
    ToolchainSpecific { basename: &'static str },
    /// This file may change for any crate within a build, or based on the CLI arguments.
    ///
    /// This differs from normal invocation-specific files because it has a resource suffix.
    InvocationSpecific { basename: &'a str },
}

In this case I think sidebar-items.js should be InvocationSpecific. However, sidebar-items.js is not generated as a SharedResource in write_shared.rs. It is generated in render/context.rs by directly writing to a file. I think we need to change it to an InvocationSpecific item.

[Nemo157]

It seems like all invocation-specific files need an additional suffix identifying this invocation, either provided on the command line along with the toolchain-suffix, or auto-generated by rustdoc.

[jsha]

Right now the invocation-specific file format appears to be:

search-20220110-1.60.0-nightly-89b9f7b28.js

What does that last part (89b9f7b28) identify?

[GuillaumeGomez]

rustdoc commit hash I think.