Fix intra-doc links on docs.rs

[jplatte]

Finally, with the help of @Nemo157, I was able to reproduce #1180 locally by adding resolver = "2" to the root workspace config. I added an extra feature that enables all of tower and tower-https features, and is picked up by docs.rs through all-features = true, which ensures all the modules we want to link to are actually there when cargo doc is run.

Fixed #1180
Closes #1184

[davidpdrsn]

Fantastic! 🎉

I cannot test it but I take your word for it 😅 I'll ship a new version end of next week.

[davidpdrsn]

The CI failure seems unrelated but not sure 🤔

[jplatte]

CI failure is likely caused by the first commit. I'll look into it when I get the time.

[lameferret]

So to reiterate, the issue was:

tower-http module intra doc link didn't work in docs.rs because the module that were being linked were behind feature flag.

And doc.rs public build was using resolver=2 which strictly needs used features to be specified which tower-http didn't, while tower crates don't have such flags, therefore intra-doc link worked fine for it.

[Nemo157]

Close. The tower crates flags don't matter here, the resolver is only set by the root crate being built. The axum crate has set edition = "2021" which implies a default of resolver = "2", but locally it's within a workspace which overrides the resolver chosen, and that workspace used the default resolver = "1". So when you build in the repository the dev-dependencies features leak into the normal doc build and activate extra features, when you extract just the axum crate out of the repository and build it on its own those features don't leak.

[jplatte]

Actually tower and tower-http both mattered, in the same way. Most links affected (at least in the doc section where I noticed) were for tower-http, but one was for tower (I think for a timeout middleware).