-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stdlib support for Apple WatchOS #98101
Conversation
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
r? @thomcc (rust-highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
8fe299f
to
cd52721
Compare
cd52721
to
b088673
Compare
☔ The latest upstream changes (presumably #95897) made this pull request unmergeable. Please resolve the merge conflicts. |
b088673
to
19630be
Compare
This owns, thanks for the PR. After asking on Zulip, it seems like we probably want T-libs-api to sign off on stuff like MetadataExt, even though it's a copy of the trait for existing platforms. Also, in all likelihood, we don't want stuff like the raw module. @rustbot label +T-libs-api -T-libs |
Hi - do I need to do anything to move this PR forward? @thomcc @Urgau |
I've nominated it to be discussed in the next libs meeting (next week), since the next steps are unclear. I probably should have done this earlier. |
Hey, the outcome of the That is, even though these are duplicates of APIs which exist already on other targets (e.g. ios), there are still multiple options for how to go about this -- as one example, it may be better to do something like re-export Thanks for the patience. |
I'll do a full review after those changes are made. @rustbot label +S-waiting-on-author -S-waiting-on-review |
Thanks - what parts are considered new apis? |
19630be
to
761fc3b
Compare
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
Sorry, I missed this comment. You seem to have gotten it though. |
library/std/src/os/mod.rs
Outdated
#[cfg(target_os = "solid_asp3")] | ||
pub mod solid; | ||
#[cfg(target_os = "vxworks")] | ||
pub mod vxworks; | ||
#[cfg(target_os = "watchos")] | ||
pub mod ios; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, can you hold off on this until another PR? Is this required to compile?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is required - what is the issue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It needs libs-api decision, I think -- the outcome of the libs meeting was just to pull this part out into another PR and land it separately if possible, so that more deliberation can happen.
I definitely don't think it should be called ios
, and there are a lot of reasons the two might diverge (they're not even quite the same architecture, for example).
Anyway, please submit a separate PR with this part (or what you had before) and we can land the rest of this, and work out what to do with the std::os
bit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok removed those parts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. I'll take another look tomorrow (it's 1am and I should double check), but I think it's probably fine to land with that.
Yes, apologies for the delay. I have changed |
761fc3b
to
eda4cbb
Compare
eda4cbb
to
439d64a
Compare
The new api parts have been split off into a separate PR here: #99497 |
Okay, did another pass on it tonight since I couldn't sleep, and this looks fine. New APIs are split out, perhaps with the exception of std::env::os, which I think is fine, since lacking that would make this OS unique, so I'm treating it as exposing an existing API on the target, which is... really what everything else in this PR is doing. Anyway, everything else seems to match (hopefully I didn't miss anything, but I've double checked at this point). @bors r+ |
Rollup of 7 pull requests Successful merges: - rust-lang#98101 (stdlib support for Apple WatchOS) - rust-lang#99345 (Do not allow typeck children items to constrain outer RPITs) - rust-lang#99383 (Formalize defining_use_anchor) - rust-lang#99436 (Add flag to configure `noalias` on `Box<T>`) - rust-lang#99483 (Fix a numerical underflow in tuple wrap suggestion) - rust-lang#99485 (Stop injecting `#[allow(unused_qualifications)]` in generated `derive` implementations) - rust-lang#99486 (Refactor: remove a string comparison between types in `check_str_addition`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
…thomcc Standard library OS support for Apple WatchOS This PR was split from rust-lang#98101
Standard library OS support for Apple WatchOS This PR was split from rust-lang/rust#98101
Standard library OS support for Apple WatchOS This PR was split from rust-lang/rust#98101
Support Apple tvOS in libstd This target has existed in the compiler for a while, was `no_std`-only previously (even requiring `#![feature(restricted_std)]`). Apple tvOS is essentially the same as iOS, down to using the same version numbering, so there's no reason for this to be a `no_std`-only target the way it is currently. Not yet tested much (I have an Apple TV, but haven't tested that this can deploy and run programs on it, nor the simulator). Uses the implementation strategy as the watchOS support in rust-lang#98101 and etc. That is, no `std::os::` interfaces aside from those in `std::os::unix`. Includes an update to libc in order to pull in rust-lang/libc#2958.
Standard library OS support for Apple WatchOS This PR was split from rust-lang/rust#98101
Standard library OS support for Apple WatchOS This PR was split from rust-lang/rust#98101
This is a follow-up to #95243 (Add Apple WatchOS compiler targets) that adds stdlib support for Apple WatchOS.
@deg4uss3r
@nagisa