restricted_std applicability to custom JSON targets

[Mark-Simulacrum]

In rust-lang/rust#120232, std's build script was moved to using the TARGET_OS and other fine-grained environment variables set by Cargo. This means that some JSON targets (regardless of filename, which is the previous filter?) do not enable the restricted_std mode.

Before stabilizing -Zbuild-std, we will want to figure out what guarantees we want to make here.

cc rust-lang/rust#71009, rust-lang/rust#38338

[ehuss]

Thanks for filing the issue! I'm a little unclear about exactly what this means, can you clarify? Is this possibly suggesting that the "std supported" flag should be in the target spec and not in std's build.rs?

I think my original intent was:

• If you create a target.json with target cfg values that match what is in std's build.rs, then you get full access to std. Presumably you are building for a custom target that is similar enough to the existing targets, and I would expect it to "just work".
• If you create a target.json with target cfg values that do not match watch is in std's build.rs, then you don't get access to std, just core (and maybe alloc?).

There is a much larger question of "I want to build for a new target, and I need to modify std to do it.", which is tracked in #3. I'm skeptical that moving just the "std supported" flag to the target spec will be sufficient for most custom targets.

If/when build-std is stabilized, I would want to ensure that rust-lang/rust#71009 is resolved first.

#6 also contains some considerations for why target-spec JSON needs a lot of work.

[Mark-Simulacrum]

I think if target specs are not stable (i.e. rust-lang/rust#71009) then this is not really a problem for build-std (any instability in std builds is under the target spec instability umbrella at that point).

The current way we decide whether std is stable or not is by matching on a small subset of the target cfg values. For example, if I am target something like wasm32-linux, that might be considered stable by the current rules in std's build script, but perhaps should not be.

I filed this mostly since we closed #60 -- there should be, IMO, some explicit decision in the RFC/FCP stabilizing build-std as to how we do the filter in std's build.rs. Right now that filter is pretty loose, we may want to tighten it (e.g., must precisely match a tier-3+ target that's in tree across all cfgs). Maybe this should be closed as a duplicate of #6.