Port Rust to PNaCl.

[DiamondLovesYou]

Modify Rust for targeting PNaCl/JS. PNaCl's newlib isn't completely vanilla (pthreads, for example), so I've for the most part kept to #[cfg]ing on target_os.

This PR also adds some code for hosting Rust on PNaCl.

[rust-highfive]

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

[richo]

Whoa amazing!

[alexcrichton]

Nice work @DiamondLovesYou! Could you actually lump all the support into this PR instead of sharding it across a few PRs? This should likely all land as a unit instead of piecemeal to make sure it's all kept track of

[alexcrichton]

s/le23/le32/

[DiamondLovesYou]

Whoops, thanks.

[brson]

We might reconsider what the requirements are for cross-compile toolchains before adding -C cross-path. We've gone through several arrangements for passing this kind of info to rustc (I actually already thought we had something for this).

[brson]

Why is all of this stuff part of the compiler driver? Are these necessary for running any NaCl code? Should rustc link them by default?

[DiamondLovesYou]

They are necessary if you'd like to spawn and manage child processes. Which rustc does; rustdoc may not currently, but there's no harm in adding the libs in case rustdoc starts spawning processes at some future date. They also capture stdout/stderr for piping etc, setup env vars (like what a you'd expect on a regular platform), and provide program argument access (in the same way as one would expect for a normal platform).

They should not be default. It would introduce a false dep on all those libs for pure PPAPI plugins (like those using rust-ppapi) which should only depend on the C PPAPI.

[DiamondLovesYou]

Actually, rust-ppapi (or any pure Rust wrapper over PPAPI) can't be used at all with ppapi_cpp; both define the main PPAPI functions: PPP_InitializeModule, PPP_ShutdownModule, and PPP_GetInterface.

[brson]

@DiamondLovesYou I tried to go through and add suggestions about how to abstract away pnacl-specific parts, but I didn't get through the whole patch.

[DiamondLovesYou]

@brson

We might reconsider what the requirements are for cross-compile toolchains before adding -C cross-path. We've gone through several arrangements for passing this kind of info to rustc (I actually already thought we had something for this).

In the past, Android's cross used it as well. It was removed around a year ago (was mildly annoying for me when it happened too).

Either way, rustc will also check for $NACL_SDK_ROOT (because cargo) if -C cross-path isn't specified.

[DiamondLovesYou]

I need to do a rebase so I can pick up the changes for LLVM 3.7.

[DiamondLovesYou]

In order to save the comments on the various commits of this PR from the deletions of a rebase, I've created a new PR: #26505.

[ctaggart]

From the bleachers, I find the idea of this very exciting. Being able to build portable native Chrome apps using Rust would be pretty awesome. 👍

[DiamondLovesYou]

@ctaggart Thanks! Once this lands in pepper_canary, you'll be able to build #26505 with PNaCl cross support. Until then, you can just manually replace llvmdeps.rs' contents with (after Rust's build has generated the file):

#[link(name = "LLVM-3.7.0svn")]
#[link(name = "pthread")]
#[link(name = "rt")]
#[link(name = "dl")]
#[link(name = "m")]
#[cfg_attr(not(target_env = "msvc"), link(name = "c++"))]
extern {}

Configure with /path/to/branch/configure --target=le32-unknown-nacl --enable-clang --enable-libcpp --nacl-cross-path=$NACL_SDK_ROOT

[alexcrichton]

Closing in favor of #26505