Redetermining `rustc-docs`'s target tuple(s)

[rami3l]

Background

Continuation of #75833, part of rust-lang/rustup#3717:

Thanks to my previous #150289, in today's nightly we can already find rustc-docs that can be installed correctly without conflicts, so #75833 has technically been resolved.

Problem Description

However, there is another possible inconsistency that might be undesirable for announcing its availability on rustup, namely you cannot do rustup component add rustc-docs unless your host tuple is x86_64-unknown-linux-gnu:

[..] only rustc-docs-x86_64-unknown-linux-gnu exist so you'll have to type that, unless you are really on an x86_64-unknown-linux-gnu host where we'll append the host tuple to the end for you.
rust-lang/rustup#3717

Expected Outcome

I think rustc-docs-[HOST_TUPLE] should at least exist on the release server as well as in the manifest, just like rust-docs-[HOST_TUPLE] does today.

Challenges

It seems to me that the biggest problem of fixing this is whether it should be implemented as rustc-docs compiled to all major host platforms, or simply as the same rustdoc with different component names. It should be noted in addition that the current online version that many are using seems to be x86_64-unknown-linux-gnu-only.

The previous Zulip discussion on this topic is here.

I'd love to propose a PR if needed as long as the above uncertainty is settled.

[Urgau]

I don't think rustc docs are not really meaningfully different on other hosts, and as you note the online version only use x86_64-unknown-linux-gnu and we haven't heard from anyone that the docs are missing something.

[bjorn3]

Can we make the rustc-docs component host independent?

[rami3l]

Can we make the rustc-docs component host independent?

@bjorn3 rustup certainly can treat it like that, but my questions are rather: Is it really so? Also, why is rust-docs host-dependent?

[bjorn3]

None of the rustc internal crates should should have a different api depending on the host.

Also, why is rust-docs host-dependent?

I believe that is just the default for components.

[rami3l]

None of the rustc internal crates should should have a different api depending on the host.

@bjorn3 Thanks for the insight! Can we say the same to other stuff on that page though? I am particularly worried about e.g. cargo and friends (cc @weihanglo).

I believe that is just the default for components.

I guess we'll just ship the same component under different names then!

[rami3l]

I asked @blyxyas and got more or less the same response. In addition, she did remind me that I should've done a rough check on how target-based conditional compilation is used across the codebase.

So here's her command, slightly modified, and its output...

> git log -1
commit 04813e4de86a5e024e71756ef092637aa862c984 [..]

> rg 'cfg\\((windows|unix|target_(?:os|env|arch))' -l -g='*.rs' -g='!library/' -g='!rust-analyzer/' -g='!*test*' -g='!*example*'
src/build_helper/src/fs/mod.rs
src/bootstrap/src/utils/job.rs
src/bootstrap/src/utils/helpers.rs
src/bootstrap/src/lib.rs
src/bootstrap/src/bin/rustc.rs
src/bootstrap/src/bin/main.rs
compiler/rustc_span/src/analyze_source_file.rs
compiler/rustc_lint_defs/src/builtin.rs
src/bootstrap/src/core/config/config.rs
compiler/rustc_codegen_cranelift/src/debuginfo/unwind.rs
src/tools/x/src/main.rs
compiler/rustc_codegen_cranelift/src/debuginfo/line_info.rs
src/bootstrap/src/core/build_steps/install.rs
compiler/rustc_codegen_gcc/build_system/src/utils.rs
src/bootstrap/src/core/build_steps/toolstate.rs
src/tools/rustfmt/src/modules/visitor.rs
compiler/rustc_codegen_cranelift/src/compiler_builtins.rs
src/bootstrap/src/core/build_steps/clean.rs
compiler/rustc_codegen_gcc/build_system/src/rust_tools.rs
compiler/rustc_codegen_cranelift/scripts/rustdoc-clif.rs
compiler/rustc_codegen_cranelift/scripts/cargo-clif.rs
compiler/rustc_codegen_cranelift/scripts/rustc-clif.rs
compiler/rustc_data_structures/src/stack.rs
compiler/rustc_errors/src/lock.rs
src/tools/rustfmt/src/parse/parser.rs
src/tools/rustfmt/src/lib.rs
compiler/rustc_codegen_ssa/src/back/apple.rs
compiler/rustc_codegen_ssa/src/back/link.rs
compiler/rustc_fs_util/src/lib.rs
compiler/rustc_codegen_ssa/src/back/write.rs
compiler/rustc_codegen_ssa/src/back/command.rs
compiler/rustc_expand/src/module.rs
src/librustdoc/html/highlight/fixtures/sample.rs
compiler/rustc_session/src/filesearch.rs
src/tools/run-make-support/src/macros.rs
src/tools/run-make-support/src/fs.rs
src/tools/clippy/clippy_dev/src/utils.rs
src/tools/clippy/clippy_dev/src/lint.rs
src/tools/run-make-support/src/command.rs
src/tools/clippy/clippy_dev/src/setup/toolchain.rs
src/tools/clippy/clippy_dev/src/serve.rs
compiler/rustc_driver_impl/src/lib.rs
compiler/rustc_metadata/src/creader.rs
compiler/rustc_metadata/src/fs.rs
src/tools/html-checker/main.rs
compiler/rustc_lint/src/builtin.rs
src/tools/rust-installer/src/util.rs
src/tools/lld-wrapper/src/main.rs
src/tools/tidy/src/extra_checks/mod.rs
src/tools/miri/src/shims/windows/foreign_items.rs
src/tools/tidy/src/bins.rs
src/tools/tidy/src/pal.rs
src/tools/clippy/clippy_lints/src/attrs/mod.rs
src/tools/miri/src/bin/log/tracing_chrome_instant.rs
src/tools/miri/src/shims/unix/fs.rs
src/tools/miri/cargo-miri/src/util.rs
src/tools/miri/src/shims/native_lib/mod.rs
src/tools/miri/src/shims/native_lib/trace/parent.rs
src/tools/miri/src/shims/os_str.rs
src/tools/generate-windows-sys/src/main.rs

... that's a total of 60 files out of 3209 candidates (given by rg '.'), so roughly < 2% of all the Rust sources.

[weihanglo]

I am fine building only for limited hosts or even just one host. Users of internal API are usually capable enough to figure out the platform difference. For cargo we have doc generated mostly for platform agnostics docs like this than API docs.

[rami3l]

So the consensus from both this thread and the previous Zulip discussion is that the host platform difference is minimal and can be ignored in most cases.

Given that, I propose that we should ship the existing rustc-docs-x86_64-unknown-linux-gnu directly under the host tuple to mirror the behavior of the rust-docs component. Update: rust-docs' behavior turns out to be a bit more complex than that, but the principle stays the same. See #151080 for more details.