Expose std support via --print

[adamgemmell]

As discussed on Zulip, this RFC proposes adding a new argument for rustc --print that acts as the single source of truth for whether a target supports std.

Rendered

[ehuss]

I don't know what process the compiler team wants to use, but typically in the past they have been using the Major Change Proposal process for new flags and such like this (instead of an RFC).

[davidtwco]

I don't know what process the compiler team wants to use, but typically in the past they have been using the Major Change Proposal process for new flags and such like this (instead of an RFC).

I think the line is a bit blurry, our documentation says:

It can also be used for small user-facing changes like adding new compiler flags, though in that case we also require an rfcbot fcp to get full approval from the team.

Is this a small user-facing change? Probably? Given that an RFC has been written and it'll be subject to an FCP anyway, I think we might as well keep it as an RFC.

[davidtwco]

I think this is a sensible addition to --print¹. I don't think we need to worry about adding options to that flag.

Footnotes

1. for the sake of transparency: @adamgemmell and I work for the same employer and I've reviewed this internally already. ↩

[petrochenkov]

What does "std support" means exactly? You can, for example, make you own crate and make it the std library.

Having an std library shipped is not a property of the compiler, it's a property of the distributed toolchain, similarly to having the LLD linker shipped, for example.
How is compiler going to implement this --print option

• Report some hardcoded value set during at toolchain's build time?
• Actually start the crate loader and search for the crate named std?

The distribution itself can potentially ship a json file describing its components (rustup already does something like that?), then rustc --print can point to the location of that json file.

[adamgemmell]

From my perspective rustc already treats core/std/others as special when it comes to the sysroot and attributes like #![no_std] or #![no_core]. In addition, these crates are versioned with the compiler and you can't expect to mix and match compiler and std versions, even for different nightlies for the same release version. Hence I think the term std is already unambigious except for the case where users write their own standard library crates. I can define std more strictly in the RFC to reflect this.

The RFC goes into implementation details - it's going to use an existing field in the Target spec. The output can be changed by using a custom JSON target but if a user's custom std doesn't support a target and the user wants to use a built-in target then I think I agree with your concerns. I'm not sure if people do that or what guarantees the compiler makes for people who write their own std crates.

[davidtwco]

Having an std library shipped is not a property of the compiler, it's a property of the distributed toolchain, similarly to having the LLD linker shipped, for example.

To add to what @adamgemmell said, this flag isn't that related to whether a std is shipped for a target. With something like -Zbuild-std, you can build a std that isn't shipped, and on some targets that just won't build, or maybe it will but will panic unexpectedly - in that circumstance, we'd like to be able to know "this std isn't going to work" so that we can give the user a helpful message to that effect rather than a potentially confusing build error that they can't easily action.

[adamgemmell]

if a user's custom std doesn't support a target and the user wants to use a built-in target

Looking back at this I'm not sure it's a concern. Whether a target can support std is still a property of the target (i.e. whether it has a suitable OS) and as the RFC says the flag doesn't attempt to differentiate targets with a "broken" std.

[wesleywiser]

I think this is a reasonable addition to the --print command. What do you all think?

@rfcbot fcp merge

[rfcbot]

Team member @wesleywiser has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Aaron1011
• @cjgillot
• @compiler-errors
• @davidtwco
• @eddyb
• @estebank
• @jackh726
• @lcnr
• @matthewjasper
• @nagisa
• @oli-obk
• @petrochenkov
• @pnkfelix
• @wesleywiser

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[nagisa]

I want to second @petrochenkov's questions. In my mind a lot of the motivation reads as a desire to add a mechanism to "ask" before doing. It then again motivates that this is to avoid confusion by the users of -Zbuild-std. It seems to me that this particular problem could be addressed from a direction of "just doing" and then figuring out how to provide personalized diagnostics if the desired action does not succeed. It could be as simple as

// in std/lib.rs
#[cfg(not(supported_platform))]
compile_error!("libstd is not supported for $platform");

or whatever, with huge benefit of such approach being that the support for libstd remains entirely within confines of libstd without affecting the implementation of the compiler in an orthogonal way.

[adamgemmell]

Sorry for the silence here. First of all, I think there's two concepts I'm trying to express as one here that need to be separate:

1. Whether a target can conceptually support std. This is build-std's and the platform doc's concern and a property of the compiler's definition of the target.

2. Whether a target currently supports shipping std. This is bootstrap's concern and a property of the std implementation. The set of targets for which this is true should be a subset of those for which 1. is true.

For the vast majority of targets these booleans are the same though there's some weird edge cases that I really don't understand. For example, the majority of targets that don't contain "-none" in their name are marked as supporting std in bootstrap, though i586-pc-windows-msvc is a distributed target that shouldn't support std according to platform docs but isn't marked no_std in bootstrap.

I'm ok with adding a perma-unstable "std_supported" cfg option which would represent concern 1, though that's effectively a minor improvement of the solution currently in place today. Note that still requires the compiler to have an opinion here, which I think goes against the end of your message but I think this would be ok.

I'm interested in what the Cargo team thinks of it - rust-lang/cargo#14183 was merged recently which is a soft check for the Metadata.std field in the target-spec before attempting to build std, with the aim of replacing the mechanism with this RFC in future to make the check more robust.