Implement libstd for CloudABI.

[EdSchouten]

Though CloudABI is strongly inspired by POSIX, its absence of features that don't work well with capability-based sandboxing makes it different enough that adding bits to sys/unix will make things a mess. This change therefore adds CloudABI specific platform code under sys/cloudabi.

One of the goals of this implementation is to build as much as possible directly on top of CloudABI's system call layer, as opposed to using the C library. This is preferred, as the system call layer is supposed to be stable, whereas the C library ABI technically is not. An advantage of this approach is that it allows us to implement certain interfaces, such as mutexes and condition variables more optimally. They can be lighter than the ones provided by pthreads.

This change disables some modules that cannot realistically be implemented right now. For example, libstd's pathname abstraction is not designed with POSIX *at() (e.g., openat()) in mind. The *at() functions are the only set of file system APIs available on CloudABI. There is no global file system namespace, nor a process working directory. Discussions on how to port these modules over are outside the scope of this change.

[rust-highfive]

r? @sfackler

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

[alexcrichton]

Thanks for the PR @EdSchouten!

We discussed this PR at @rust-lang/libs triage today and we noted that one thing we'll probably want to do is keep the whole standard library compiling as-is on the cloudabi platform (e.g. continue to have std::net and such). We very much agree that it would be best to not have functionality compiled into libstd that forces a shim that always returns an error, but we're not quite ready to do this just yet. Notably we're missing an implementation of the portability lint and (as I'm sure you've discovered) the literal code organization of the standard library isn't currently amenable to cfg'ing out modules on some platforms and not others.

Along those lines could this take a wasm-like approach which implements the entire sys layer as expected by the standard library (withough cfg'ing off anything in the standard library) and simply returning errors from anything that the cloudabi platform doesn't implement? (this is what the wasm platform does). Eventually down the road we'll equip the standard library to remove these shims and actually delete all the always-returns-an-error code, but initially it'll be easier to not put cfg annotations in the standard library for that.

[EdSchouten]

Hi Alex,

Thanks to you and others for taking the time to discuss this! I have to say I only agree with this sentiment partially; I already had a set of patches that made a full ./x.py test && ./x.py dist pass that weren't a lot more complex than with shims in place. That said, I do understand that providing shims will make it easier to get started and puts less of a burden on the project.

I've just updated this pull request with three additional commits: one to put shims in place and two to make all of the tests/documentation build properly. Be sure to let me know what you think!

Ed

[EdSchouten]

Hmmm... this is odd. Checks fail due to cfg(target_os = "cloudabi") being used in generic code, but those places already used target_os = "emscripten". What would be the preferred way of solving this?

[alexcrichton]

Looks like there may be a specific exception for these lines but the modification is triggering it again?

[alexcrichton]

(in that it should be fine to just tweak that exception logic)

[alexcrichton]

@bors: r+

[bors]

📌 Commit 6a8d55a has been approved by alexcrichton

[EdSchouten]

Sorry if I'm being impatient, but is this pull request actually in bors's queue? I'm seeing most pull requests getting merged by bors within one day, whereas this one is taking almost three days.

Just responding to this pull request to ensure it won't slip under the radar. There happened to be an outage on GitHub around the time this got approved. Maybe this interfered with it being queued?

[bors]

⌛️ Testing commit 6a8d55a with merge 48ab4cd...

[petrochenkov]

@EdSchouten

is this pull request actually in bors's queue? I'm seeing most pull requests getting merged by bors within one day, whereas this one is taking almost three days.

You can see the queue here - https://buildbot2.rust-lang.org/homu/queue/rust.
Pull requests are merged in order from oldest to newest (unless manually prioritized or rolled up).
Time until merge can vary a lot depending on several factors, so waiting for several days is not unusual.

[EdSchouten]

Hey @petrochenkov. Thanks for the link. That's pretty useful!

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 48ab4cd to master...

[RalfJung]

@EdSchouten What is the reason you used UnsafeCell<AtomucU32>? That does not make much sense. AtomucU32 already contains an UnsafeCell (in fact, it has to).