Add sysroot detection in rustdoc

[robinmoussu]

When building rustdoc without using x.py, the sysroot is not going
to be detected automatically. It wasn't an issue when using x.py, and
this commit should not have any effect when building rustdoc as part
of the rustc build.

Note: if you want to build rustdoc out-of-tree, you need to install the
rustup components rustc-dev and llvm-tools-preview.

r? @simulacrum
@jyn514

[robinmoussu]

I'm not 100% sure that it's the most readable way to update the Vec<String> in this Option.

[Mark-Simulacrum]

r? @jyn514

I think this is probably "fine" though I'm not personally really all that happy to see it. It seems like it may be worthwhile to consider putting this logic in rustc_driver (or similar), though, to avoid duplicating it into all the tools.

[RalfJung]

At least for Miri, I don't see how to easily move this logic to rustc_driver. We specifically want to capture environment variables set during the Miri build, not when the librustc_driver for the sysroot gets built.

What would help, however, is if whoever instantiates the driver could affect get_or_default_sysroot to use a different default sysroot.

[Mark-Simulacrum]

Well, we could macro-ize it or something to get the expansion to be in the miri build I guess.

I imagine it should be possible to provide a global static of some kind that drivers can set to affect get_or_default_sysroot though.

[robinmoussu]

Where should this code be moved? In a macro in rustc_driver?

[RalfJung]

This code is a hack needed to avoid changing the code in rustc itself. IMO it makes no sense to move it to move it to the rustc repo. If rustc wants to support this usecase, instead get_or_default_sysroot should be changed to allow drivers to overwrite the default sysroot.

[RalfJung]

Specifically, this code hard-codes the default sysroot to be "one path above the binary":

rust/compiler/rustc_session/src/filesearch.rs

Lines 128 to 131 in a3d7a5e

	let mut p = canonicalize(exe);
	p.pop();
	p.pop();
	p

That doesn't work for Miri, which is why it needs that hack which this PR copies to rustdoc.

[flip1995]

FYI: Clippy does this too: https://github.com/rust-lang/rust-clippy/blob/408b615d3451d00c21b303fd8aeb74b77970a4a9/src/driver.rs#L301-L344

Summary:

        // Get the sysroot, looking from most specific to this invocation to the least:
        // - command line
        // - runtime environment
        //    - SYSROOT
        //    - RUSTUP_HOME, MULTIRUST_HOME, RUSTUP_TOOLCHAIN, MULTIRUST_TOOLCHAIN
        // - sysroot from rustc in the path
        // - compile-time environment
        //    - SYSROOT
        //    - RUSTUP_HOME, MULTIRUST_HOME, RUSTUP_TOOLCHAIN, MULTIRUST_TOOLCHAIN

The compile time sysroot is only the fallback for us. This is because we need clippy_driver to also work on single files, just like rustc, IIRC. (The discussion about this starts here: rust-lang/rust-clippy#5071 (comment))

[robinmoussu]

I am not sure that I understand why I need to do to make this issue progress forward. Could you guide me?

[jyn514]

@robinmoussu right now the default sysroot is hard-coded in rustc. It should be configurable by tools (or any program using rustc_private) so they don't need to add the hack you're adding here. #78926 (comment) has some suggestions on what code to change.

[crlf0710]

@robinmoussu Ping from triage, any updates on this?

[jyn514]

@crlf0710 this is a good refactor to have, but it's not really what @robinmoussu signed up for when he made the PR. Also it will probably not be used by rustdoc even if merged, since #79540 is more the approach I see the team taking, we are not currently planning to switch rustdoc to building out of tree.

So if @robinmoussu wants to keep working on this more power to him, but I think it makes more sense for @RalfJung or @flip1995 to pick it up since they're the ones that will use it (or we can just make this an issue since the PR implementation is not on the right track).

[robinmoussu]

I agree with what @jyn514 said. Given that my bandwidth is more limited that what I'd like, I will not be able to work on it more than that. You can totally close this PR if you think it's not useful as-it.

[RalfJung]

Okay, let's close it then. Thanks @robinmoussu for exploring this solution, even if it did not work out!