r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
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

Unknown labels: O-visionos

Unknown labels: O-visionos

triagebot.toml has been modified, there may have been changes to the review queue.

cc @davidtwco, @wesleywiser

r? libs

Sorry, accidentally deleted the branch

r? libs-api

There could be an umbrella namespace for these common stuffs, e.g. apple like cfg(target_vendor="apple").

I think std::os::apple is a good idea, but I think it's somewhat separate from this proposal; even if we have std::os::apple, I think I'd still want std::os::tvos/std::os::watchos/std::os::visionos for consistency with std::os::macos/std::os::ios (unless we fully deprecate the latter).

Implementation-wise, it could just be pub use apple as ios;.

I would rather avoid having to include a new submodule every time apple designs a new device and instead centralize everything under a single submodule. For backwards-compatibility, std::os::macos can be a re-export of std::os::apple, but I don't think we should add more.

Hello,

I was there for some of the discussion of this nature because I reviewed the tvos PR and a few others. It basically went exactly like this discussion. There is no point in having all these different APIs exposed when they introduce a somewhat-pointless risk for additional variance.

It may be prudent to use the kernel name... i.e. mod darwin... that AIUI they all share, because there is The Other MacOS from long ago. Apple is clearly willing to have epochal breaking changes that risk redefining what mod apple would mean. Rosetta 2 implies its own sequel, a Rosetta III: Translator's Revenge.

I opened #125935 to do the refactor and fixing the compilation errors separately, so that this PR can be focused on the public API. Will rebase once that lands.

It may be prudent to use the kernel name... i.e. mod darwin

Well, the kernel name is technically XNU, it's the broader core OS that's named Darwin, but your point still stands. I think it could be a pretty good name to use, were it not for the fact that the macOS targets use it in their names as well (e.g. aarch64-apple-darwin), which might be confusing?

A bit of prior art:

• Swift has import Darwin for Apple-specific stuff, and #if os(Darwin) ... #endif for Apple-specific configs.
• C/Objective-C has TargetConditionals.h which defines TARGET_OS_MAC for this purpose (TARGET_OS_OSX is the one for macOS-specific code).
• Python's platform.system() returns Darwin on macOS and iOS on iOS, while os.uname() returns Darwin on both.

In an ideal world, I think I'd want:

1. cfg(target_family = "darwin") (or just cfg(darwin)).
2. The macOS targets to be named *-apple-macos.
3. std::os::darwin.

So if we can agree that plan is to move in this direction (i.e. at some point slowly rename the targets, and at some point add target_family = "darwin"), then I think std::os::darwin makes sense; if not, then we should probably go with std::os::apple.

In an ideal world, I think I'd want:

1. cfg(target_family = "darwin") (or just cfg(darwin)).
2. The macOS targets to be named *-apple-macos.
3. std::os::darwin.

So if we can agree that plan is to move in this direction (i.e. at some point slowly rename the targets, and at some point add target_family = "darwin"), then I think std::os::darwin makes sense; if not, then we should probably go with std::os::apple.

Yes, I was in particular thinking that the target_family cfg proposed for the phase out of target_vendor should be named thus in accord with this. Ideally we would get aarch64-apple-macos as a target tuple (since the target_os is "macos" anyways), but that may prove the harder part.

We discussed this in today's @rust-lang/libs-api meeting. Our consensus was that we don't want to provide a different module for every Apple OS, and that we should only provide distinct modules if they have distinct functions that don't exist on the other OSes. Please just provide the std::os::apple module with the common functionality across all Apple OSes.

macos should re-export apple and also provide the deprecated items; apple shouldn't have the deprecated items.

It looks like #125935 performed the merge we asked for; thank you!

Is there anything else that needs to happen here? Is the new std::os::darwin available on tvOS/visionOS/watchOS?

I have updated this PR to instead make std::os::darwin::fs public. Since the exposed API surface here isn't really new, I propose to just make this insta-stable ¹.

Summary

std::os::darwin is available on cfg(target_vendor = "apple") (macOS, iOS, tvOS, visionOS and watchOS), and contains functionality specific to those operating systems. It is named "Darwin" because that's the name of the underlying operating system that all of these are built upon. This follows the naming convention in Swift (import Darwin), so while it's a little bit unknown, it should be fairly familiar to developers for Apple platforms.

The API for std::os::darwin is:

The API for std::os::macos and std::os::ios is now:

Note: The images here doesn't show it, but MetadataExt::as_raw_stat is only available on macOS and iOS.

In the future, we can consider deprecating std::os::macos and std::os::ios, but this PR does not propose that.

@rustbot ready

Responding to #123723 (comment):

• Do not expose std::os::{tvos, visionos, watchos}::raw — those modules will be changed to pub(crate). For macos, raw has been deprecated since more than 8 years ago and I think it's worth avoiding adding that deprecated API in yet another place. Note that the 9 type aliases will continue to be accessible as re-exports in std::os::unix::raw, where they have been stably accessible on tvos, visionos, and watchos since the original introduction of these targets. For future unix targets, we may wish to avoid re-exporting raw deprecated types for them in std::os::unix::raw in the first place.

Only std::os::darwin::fs is exposed, std::os::darwin::raw is pub(crate) and instead exposed publicly in std::os::unix::raw, std::os::macos::raw and std::os::ios::raw.

• Do not include as_raw_stat in the MetadataExt trait of the new targets. On macos this trait method has been deprecated since Rust 1.8.

This is cfg-gated to only be available on macOS and iOS.

• Seal the MetadataExt trait of the new targets.

I'm not entirely sure of a good way to do this without complex macros? trait MetadataExt: #[cfg(...)] Sealed doesn't work.

r? libs-api

FCP checkboxes are back in this now-hidden comment, in case you're wondering why you can't find them: #123723 (comment)