std: Add Motor OS std library port

[lasiotus]

Motor OS was added as a no-std Tier-3 target in
PR 146848 as x86_64-unknown-motor.

This PR adds the std library for Motor OS.

While the PR may seem large, all it does is proxy
std pal calls to moto-rt. Where there is some non-trivial
code (e.g. thread::spawn), it is quite similar, often
identical, to what other platforms do.

[rustbot]

These commits modify the library/Cargo.lock file. Unintentional changes to library/Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

The list of allowed third-party dependencies may have been modified! You must ensure that any new dependencies have compatible licenses before merging.

cc @davidtwco, @wesleywiser

[rustbot]

r? @tgross35

rustbot has assigned @tgross35.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[tgross35]

Is there any notable std functionality that isn't supported on this platform? Just skimming it, it seems like things are pretty complete (threads, systemtime, process, etc)

Nominating for libs as this adds a new std target.

@rustbot label +I-libs-nominated

[lasiotus]

Is there any notable std functionality that isn't supported on this platform? Just skimming it, it seems like things are pretty complete (threads, systemtime, process, etc)

I believe all major pieces are supported/implemented, including networking. Some specific things are not (yet) fully implemented, like FS links, or DNS lookup (at the moment, only "localhost" resolves to an IP address). On the other hand, tokio is ported via a mio port, which was not completely trivial...

[bors]

☔ The latest upstream changes (presumably #147019) made this pull request unmergeable. Please resolve the merge conflicts.

[Amanieu]

We discussed this in the @rust-lang/libs meeting and are happy to add std support for this target because it supports all major functionality of std.

[lasiotus]

We discussed this in the @rust-lang/libs meeting and are happy to add std support for this target because it supports all major functionality of std.

Thanks, Amanieu!

@tgross35 Trevor, how can I improve this PR to make it mergeable?

[tgross35]

It's on my list, I just haven't had a chance to do a thorough review yet (probably later this week)

[lasiotus]

I believe I have addressed all comments now. Thanks for the detailed review, the PR is definitely better now than what it was two weeks ago!

[tgross35]

Looks pretty good for me! Just a few small requests then I think this should be set.

View changes since this review

[tgross35]

It would be good to format this as

// SAFETY: All variants have `sin_family` at the same offset
let family = unsafe { addr.v4.sin_family };
match family { ... }

[lasiotus]

Comment on lines +453 to +459

    unsafe {
        match addr.v4.sin_family {
            netc::AF_INET => SocketAddr::V4(crate::net::SocketAddrV4::from(addr.v4)),
            netc::AF_INET6 => SocketAddr::V6(crate::net::SocketAddrV6::from(addr.v6)),
            _ => panic!("bad sin_family {}", addr.v4.sin_family),
        }
    }

Contributor
@tgross35 tgross35 2 hours ago

It would be good to format this as

// SAFETY: All variants have `sin_family` at the same offset
let family = unsafe { addr.v4.sin_family };
match family { ... }

This is done/fixed. For some reason I can't add comments to or resolve the comment above (a github bug?).

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.