fix(rustdoc): always use a channel when linking to doc.rust-lang.org

[poliorcetics]

Closes #131971

I manually checked the resulting links

One issue is that this will create nightly/... links in places that formerly linked to stable, is that ok ? (the slice and array links in the search help notably)

[rustbot]

r? @fmease

rustbot has assigned @fmease.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred in HTML/CSS/JS.

cc @GuillaumeGomez, @jsha

[camelid]

Makes sense to me. r=me with CI fixed (just tidy line-length errors)

[GuillaumeGomez]

I'm not sure it's the right fix: currently it's only targeting the same channel whereas the issue is about the same version as rustdoc when the doc is generated.

[camelid]

I'm not sure it's the right fix: currently it's only targeting the same channel whereas the issue is about the same version as rustdoc when the doc is generated.

Sure, this is more of an existing limitation of DOC_RUST_LANG_ORG_CHANNEL though, right? We could just change it to use the 1.x.x version instead of stable to resolve your concern right?

[GuillaumeGomez]

Not sure... I suppose it could work, but on nightly, the item we're targeting might not be there when the current version is release 12 weeks later. Tricky problem.

[camelid]

Not sure... I suppose it could work, but on nightly, the item we're targeting might not be there when the current version is release 12 weeks later. Tricky problem.

I'm a little confused what the issue is. I'm pretty sure this PR is a strict improvement over the status quo, since we will match the version in more cases than before. In any case, these are only for a few custom links to things that don't change that much, like the slice primitive. It's not going to be going away.

[GuillaumeGomez]

Yeah, maybe you're right. But in any case, it doesn't solve the issue which wants the version and not the channel. I'm fine merging as is but it's not the fix asked in the issue.

[camelid]

@GuillaumeGomez why did the original PR introduce DOC_RUST_LANG_ORG_CHANNEL in the first place? Should we just get rid of it and always use the Rustdoc version (or beta/nightly if it's an unstable version) instead?

[GuillaumeGomez]

I think using a version unless it's beta/nightly would be the correct fix.

[camelid]

so @poliorcetics do you want to redo the PR to accomplish that? Or rather it would be a change on top of what you've already done: replace DOC_RUST_LANG_ORG_CHANNEL with DOC_RUST_LANG_ORG_VERSION or something like that, where the part after the domain is nightly, beta, or the stable version number.

[poliorcetics]

Isn't that already being done ?

rust/src/bootstrap/src/core/builder/mod.rs

Lines 1185 to 1195 in 336209e

	pub fn doc_rust_lang_org_channel(&self) -> String {
	let channel = match &*self.config.channel {
	"stable" => &self.version,
	"beta" => "beta",
	"nightly" | "dev" => "nightly",
	// custom build of rustdoc maybe? link to the latest stable docs just in case
	_ => "stable",
	};
	format!("https://doc.rust-lang.org/{channel}")
	}

[camelid]

@poliorcetics you're right, and I just confirmed by looking at the rendering for existing uses of the constant. Guillaume and I must've gotten confused (the name of the constant maybe could be improved 😅).

Can you fix the tidy errors so I can approve?

[GuillaumeGomez]

And maybe the name of the constant too please? :3

[camelid]

Yeah, let's do DOC_RUST_LANG_ORG_VERSION.

[camelid]

@poliorcetics just a gentle ping. This is so close to being ready. Pretty sure you just need to fix the redundant escape sequences issue and then I can r+.

[camelid]

Thanks!

[camelid]

@bors r+ rollup

[bors]

📌 Commit a063cf5 has been approved by camelid

It is now in the queue for this repository.