add a dist builder to build rust-std components for the THUMB targets

[japaric]

the rust-std component only contains the core and compiler-builtins (+c +mem) crates

cc #49382

• I'm not entirely sure if this PR alone will produce rust-std components installable by rustup or if something else needs to be changed
• I could have done the THUMB builds in an existing builder / image; I wasn't sure if that was a good idea so I added a new image
• I could build other crates like alloc into the rust-std component but, AFAICT, that would require calling Cargo a second time (one for alloc and one for compiler-builtins), or have alloc depend on compiler-builtins (Inject the compiler_builtins crate whenever the core crate is injected #49503 will perform that change) and have alloc resurface the "c" and "mem" Cargo features.

r? @alexcrichton

[japaric]

I could build other crates like alloc into the rust-std component ...

@alexcrichton I'd like to build other no-std crates into the rust-std component. What do you think is the best approach to take here? Perhaps make a fake std crate that depends on all the no-std crates we want to put in the component?

[oli-obk]

Perhaps make a fake std crate that depends on all the no-std crates we want to put in the component?

wouldn't it be easier at that point to undo most of this PR and strip down libstd with cfgs instead? We can also use a cfg to insert an attribute making the use of std unstable on the embedded target

[japaric]

@oli-obk that might work but I'm not sure if

• You can use custom cfgs in Cargo.toml. There's no built-in cfg to differentiate sub-architectures like ARM Cortex-A (arm-unknown-linux-gnueabihf) from ARM Cortex-M (thumbv7m-none-eabi). Though cfg(all(target_arch = "arm", target_os = "none")) would probably work fine for the built-in targets we have now.

• You can enable / disable dependencies' features on a per target basis. (ARM Cortex-M wants "mem" enabled for compiler-builtins whereas that might cause problems for targets that link to libc, which also provides memcpy).

That being said I'll give these a try on a smaller Cargo project.

[japaric]

[target.'cfg(all(target_arch = "arm", target_os = "none"))'.dependencies.cb] # THUMB
features = ["mem"]
path = "../cb"

[target.'cfg(not(all(target_arch = "arm", target_os = "none")))'.dependencies.cb] # not THUMB
path = "../cb"

seems to do the right thing dependency and feature selection wise, but I have run into a problem trying to make libstd empty: I tried to use #![cfg(..)] but that also removes the #![no_std] crate attribute (and likely the #[stable] / #[unstable] ones too) so I ended with "error[E0463]: can't find crate for std" while building std.

I could add a bunch of #[cfg(..)]s on the extern crates, mods, etc. but that sounds painful to maintain.

[parched]

How about contains("-none-") because that's the part that makes them no_std?

[japaric]

Done

[alexcrichton]

Nice!

The rustbuild changes here look good to me, but can this be folded into one of the existing dist-various-* builders instead of adding a third?

[japaric]

@alexcrichton done. Any thoughts on how to extend this to build alloc and other no-std crates?

[alexcrichton]

Hm right now there's a no_std key but perhaps there could be a final-crate = "alloc" key or something like that?

[japaric]

@alexcrichton

Hm right now there's a no_std key but perhaps there could be a final-crate = "alloc" key or
something like that?

It would have to be an array because we want to build core, compiler-builtins (+c +mem), alloc and
std_unicode and there's no single crate in the std facade that depends on all those with that exact
set of Cargo features.

---

I have tweaked the implementation:

I have created a "nostd" crate (can't be named "std" because that already exists in the workspace)
that depends on those 4 crates with the set of Cargo features we want; and have tweaked bootstrap to
build that single crate.

Let me know what you think of this implementation. I personally think it's easier to maintain a Cargo.toml than maintain some custom syntax in config.toml. The downside is that the rust-std component will contain an empty libnostd.rlib -- using extern crate nostd requires a feature gate though, and "nostd" will never become stable as it's an implementation detail of the build infrastructure.

[alexcrichton]

@japaric oh if we're unconditionally building alloc could this be done by passing -p alloc -p core -p compiler_builtins etc to Cargo?

[japaric]

@alexcrichton changed to just use -p

[alexcrichton]

@bors: r+

[bors]

📌 Commit b1015f5 has been approved by alexcrichton

[japaric]

@alexcrichton the latest nightly includes this change but there's no thumbv7m-none-eabi under rustup target list. Does something else need to be changed to make the component available?

[japaric]

The rust-std components have been uploaded (e.g. https://static.rust-lang.org/dist/2018-04-06/rust-std-nightly-thumbv7m-none-eabi.tar.xz) but the rustup manifest doesn't contain their URLs.

[alexcrichton]

@japaric aha yes indeed, I believe this list needs an update as well