visionOS Support #3568

agg23 · 2024-01-30T00:17:44Z

In preparation of xrOS (visionOS) support as a tier 3 target, this makes libc buildable for this platform by mirroring iOS and other Apple target configurations.

See rust-lang/compiler-team#642

rustbot · 2024-01-30T00:17:48Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @JohnTitor (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

@rustbot author: the review is finished, PR author should check the comments and take action accordingly
@rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

agg23 · 2024-01-30T01:16:33Z

Hm... I hadn't thought about cfgs failing because the target_os doesn't exist yet.

How is this supposed to work then? New T3 target gets added to Rust, cannot build (proper) libc, libc gets updated, Rust gets updated another time to pull that libc? Seems difficult.

bors · 2024-02-03T07:32:08Z

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

Urgau · 2024-02-14T19:48:33Z

Hm... I hadn't thought about cfgs failing because the target_os doesn't exist yet.

How is this supposed to work then? New T3 target gets added to Rust, cannot build (proper) libc, libc gets updated, Rust gets updated another time to pull that libc? Seems difficult.

@agg23 You can add an exception in the build.rs.

JohnTitor · 2024-02-25T10:08:19Z

Could you squash commits into one? The changes look good!

QuentinPerez · 2024-03-22T13:38:08Z

Hi @JohnTitor,

The PR has been squashed, do you think that's something that can be merged soon ?

Swapped to visionOS target_os

QuentinPerez · 2024-03-31T12:11:27Z

Hi there,

Sorry for being impatient, but I really need to have this pull request merged. What is missing?

Add aarch64-apple-visionos and aarch64-apple-visionos-sim tier 3 targets Introduces `aarch64-apple-visionos` and `aarch64-apple-visionos-sim` as tier 3 targets. This allows native development for the Apple Vision Pro's visionOS platform. This work has been tracked in rust-lang/compiler-team#642. There is a corresponding `libc` change rust-lang/libc#3568 that is not required for merge. Ideally we would be able to incorporate [this change](gimli-rs/object#626) to the `object` crate, but the author has stated that a release will not be cut for quite a while. Therefore, the two locations that would reference the xrOS constant from `object` are hardcoded to their MachO values of 11 and 12, accompanied by TODOs to mark the code as needing change. I am open to suggestions on what to do here to get this checked in. # Tier 3 Target Policy At this tier, the Rust project provides no official support for a target, so we place minimal requirements on the introduction of targets. > A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) See [src/doc/rustc/src/platform-support/apple-visionos.md](https://github.com/rust-lang/rust/blob/e88379034a0fe7d90a8f305bbaf4ad66dd2ce8dc/src/doc/rustc/src/platform-support/apple-visionos.md) > Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target. > * Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it. > * If possible, use only letters, numbers, dashes and underscores for the name. Periods (.) are known to cause issues in Cargo. This naming scheme matches `$ARCH-$VENDOR-$OS-$ABI` which is matches the iOS Apple Silicon simulator (`aarch64-apple-ios-sim`) and other Apple targets. > Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. > - The target must not introduce license incompatibilities. > - Anything added to the Rust repository must be under the standard Rust license (`MIT OR Apache-2.0`). > - The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the `tidy` tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to besubject to any new license requirements. > - Compiling, linking, and emitting functional binaries, libraries, or other code for the target (whether hosted on the target itself or cross-compiling from another target) must not depend on proprietary (non-FOSS) libraries. Host tools built for the target itself may depend on the ordinary runtime libraries supplied by the platform and commonly used by other applications built for the target, but those libraries must not be required for code generation for the target; cross-compilation to the target must not require such libraries at all. For instance, `rustc` built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3. > - "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are *not* limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. This contribution is fully available under the standard Rust license with no additional legal restrictions whatsoever. This PR does not introduce any new dependency less permissive than the Rust license policy. The new targets do not depend on proprietary libraries. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. This new target mirrors the standard library for watchOS and iOS, with minor divergences. > The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary. Documentation is provided in [src/doc/rustc/src/platform-support/apple-visionos.md](https://github.com/rust-lang/rust/blob/e88379034a0fe7d90a8f305bbaf4ad66dd2ce8dc/src/doc/rustc/src/platform-support/apple-visionos.md) > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions. > * This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements. > Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages. > * Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. > * In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target. I acknowledge these requirements and intend to ensure that they are met. This target does not touch any existing tier 2 or tier 1 targets and should not break any other targets.

Rollup merge of rust-lang#121419 - agg23:xrOS-pr, r=davidtwco Add aarch64-apple-visionos and aarch64-apple-visionos-sim tier 3 targets Introduces `aarch64-apple-visionos` and `aarch64-apple-visionos-sim` as tier 3 targets. This allows native development for the Apple Vision Pro's visionOS platform. This work has been tracked in rust-lang/compiler-team#642. There is a corresponding `libc` change rust-lang/libc#3568 that is not required for merge. Ideally we would be able to incorporate [this change](gimli-rs/object#626) to the `object` crate, but the author has stated that a release will not be cut for quite a while. Therefore, the two locations that would reference the xrOS constant from `object` are hardcoded to their MachO values of 11 and 12, accompanied by TODOs to mark the code as needing change. I am open to suggestions on what to do here to get this checked in. # Tier 3 Target Policy At this tier, the Rust project provides no official support for a target, so we place minimal requirements on the introduction of targets. > A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) See [src/doc/rustc/src/platform-support/apple-visionos.md](https://github.com/rust-lang/rust/blob/e88379034a0fe7d90a8f305bbaf4ad66dd2ce8dc/src/doc/rustc/src/platform-support/apple-visionos.md) > Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target. > * Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it. > * If possible, use only letters, numbers, dashes and underscores for the name. Periods (.) are known to cause issues in Cargo. This naming scheme matches `$ARCH-$VENDOR-$OS-$ABI` which is matches the iOS Apple Silicon simulator (`aarch64-apple-ios-sim`) and other Apple targets. > Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. > - The target must not introduce license incompatibilities. > - Anything added to the Rust repository must be under the standard Rust license (`MIT OR Apache-2.0`). > - The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the `tidy` tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to besubject to any new license requirements. > - Compiling, linking, and emitting functional binaries, libraries, or other code for the target (whether hosted on the target itself or cross-compiling from another target) must not depend on proprietary (non-FOSS) libraries. Host tools built for the target itself may depend on the ordinary runtime libraries supplied by the platform and commonly used by other applications built for the target, but those libraries must not be required for code generation for the target; cross-compilation to the target must not require such libraries at all. For instance, `rustc` built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3. > - "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are *not* limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. This contribution is fully available under the standard Rust license with no additional legal restrictions whatsoever. This PR does not introduce any new dependency less permissive than the Rust license policy. The new targets do not depend on proprietary libraries. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. This new target mirrors the standard library for watchOS and iOS, with minor divergences. > The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary. Documentation is provided in [src/doc/rustc/src/platform-support/apple-visionos.md](https://github.com/rust-lang/rust/blob/e88379034a0fe7d90a8f305bbaf4ad66dd2ce8dc/src/doc/rustc/src/platform-support/apple-visionos.md) > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions. > * This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements. > Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages. > * Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. > * In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target. I acknowledge these requirements and intend to ensure that they are met. This target does not touch any existing tier 2 or tier 1 targets and should not break any other targets.

agg23 · 2024-04-06T02:54:55Z

Rust tier 3 target PR has merged.

I need to figure out what in this PR is breaking the musl builds.

Add aarch64-apple-visionos and aarch64-apple-visionos-sim tier 3 targets Introduces `aarch64-apple-visionos` and `aarch64-apple-visionos-sim` as tier 3 targets. This allows native development for the Apple Vision Pro's visionOS platform. This work has been tracked in rust-lang/compiler-team#642. There is a corresponding `libc` change rust-lang/libc#3568 that is not required for merge. Ideally we would be able to incorporate [this change](gimli-rs/object#626) to the `object` crate, but the author has stated that a release will not be cut for quite a while. Therefore, the two locations that would reference the xrOS constant from `object` are hardcoded to their MachO values of 11 and 12, accompanied by TODOs to mark the code as needing change. I am open to suggestions on what to do here to get this checked in. # Tier 3 Target Policy At this tier, the Rust project provides no official support for a target, so we place minimal requirements on the introduction of targets. > A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) See [src/doc/rustc/src/platform-support/apple-visionos.md](https://github.com/rust-lang/rust/blob/e88379034a0fe7d90a8f305bbaf4ad66dd2ce8dc/src/doc/rustc/src/platform-support/apple-visionos.md) > Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target. > * Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it. > * If possible, use only letters, numbers, dashes and underscores for the name. Periods (.) are known to cause issues in Cargo. This naming scheme matches `$ARCH-$VENDOR-$OS-$ABI` which is matches the iOS Apple Silicon simulator (`aarch64-apple-ios-sim`) and other Apple targets. > Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. > - The target must not introduce license incompatibilities. > - Anything added to the Rust repository must be under the standard Rust license (`MIT OR Apache-2.0`). > - The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the `tidy` tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to besubject to any new license requirements. > - Compiling, linking, and emitting functional binaries, libraries, or other code for the target (whether hosted on the target itself or cross-compiling from another target) must not depend on proprietary (non-FOSS) libraries. Host tools built for the target itself may depend on the ordinary runtime libraries supplied by the platform and commonly used by other applications built for the target, but those libraries must not be required for code generation for the target; cross-compilation to the target must not require such libraries at all. For instance, `rustc` built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3. > - "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are *not* limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. This contribution is fully available under the standard Rust license with no additional legal restrictions whatsoever. This PR does not introduce any new dependency less permissive than the Rust license policy. The new targets do not depend on proprietary libraries. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. This new target mirrors the standard library for watchOS and iOS, with minor divergences. > The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary. Documentation is provided in [src/doc/rustc/src/platform-support/apple-visionos.md](https://github.com/rust-lang/rust/blob/e88379034a0fe7d90a8f305bbaf4ad66dd2ce8dc/src/doc/rustc/src/platform-support/apple-visionos.md) > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions. > * This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements. > Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages. > * Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. > * In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target. I acknowledge these requirements and intend to ensure that they are met. This target does not touch any existing tier 2 or tier 1 targets and should not break any other targets.

madsmtm · 2024-04-10T11:43:28Z

I think this may need to be based on the libc-0.2 branch, as that's where we want it to go?

agg23 · 2024-04-10T15:43:31Z

Fixed the branch target. Still having the weird test failure, just in a slightly different way. Still don't know what to do about it.

rudyrichter · 2024-04-15T19:15:12Z

@agg23 I think #3660 unblocks things here

madsmtm · 2024-04-18T21:47:19Z

@agg23 could you rebase this on the latest master? Then I think the CI would build.

agg23 · 2024-04-18T22:16:00Z

It's not as straightforward as that, as the change happened to main, not libc-0.2. I have cherry picked the commit in question, though I am not sure if that's the right action to take.

rudyrichter · 2024-04-19T20:42:21Z

@JohnTitor should this be targeting the 0.2 or main(1.0) branch? which is slated to have a release in the near term?

coolbluewater · 2024-04-26T05:35:35Z

@JohnTitor, could you please respond so that this PR can move forward?

JohnTitor · 2024-04-26T09:50:02Z

@JohnTitor should this be targeting the 0.2 or main(1.0) branch? which is slated to have a release in the near term?

Should be shipped on 0.2 as 1.0 would require much more time to release 👍

@JohnTitor, could you please respond so that this PR can move forward?

👋 Sorry, I've been OSSing in my spare time and failed to find time recently.

coolbluewater · 2024-04-27T07:09:33Z

Thanks! Do we know when this will appear in rust nightly?

madsmtm · 2024-04-27T12:29:43Z

Once the next release of libc happens, I'll post a PR to update it in rust-lang/rust

madsmtm · 2024-04-30T14:46:06Z

I've posted rust-lang/rust#124560.

I would like to respond to the rest of your comments, but such discussion is not appropriate on this issue. Are you on Zulip? Maybe you could DM me there?

EDIT: It appears that their comments have been removed.

Swapped to visionOS target_os (apply <rust-lang#3568> to `main`) [resolve conflicts - Trevor] (cherry picked from commit b5b0f69)

Swapped to visionOS target_os (apply <rust-lang#3568> to `main`) [ resolve conflicts - Trevor ] (cherry picked from commit b5b0f69)

rustbot assigned JohnTitor Jan 30, 2024

rustbot added the S-waiting-on-review label Jan 30, 2024

agg23 force-pushed the main branch from 42c33d4 to 5a96762 Compare February 15, 2024 00:07

agg23 mentioned this pull request Feb 21, 2024

Add aarch64-apple-visionos and aarch64-apple-visionos-sim tier 3 targets rust-lang/rust#121419

Merged

agg23 force-pushed the main branch from a0aa71e to 06bda59 Compare February 25, 2024 14:53

SteveLauC mentioned this pull request Mar 4, 2024

Add visionos (Apple VisionOS) to apple_targets when it is supported by rustc nix-rust/nix#2298

Closed

agg23 force-pushed the main branch from 2818ed1 to 014bfe6 Compare March 8, 2024 17:08

xrOS support

b5b0f69

Swapped to visionOS target_os

agg23 changed the title ~~xrOS support~~ visionOS Support Apr 6, 2024

QuentinPerez mentioned this pull request Apr 10, 2024

Add Apple visionOS support tokio-rs/mio#1773

Closed

madsmtm mentioned this pull request Apr 10, 2024

Add visionOS support rust-lang/cc-rs#1029

Merged

agg23 force-pushed the main branch from 014bfe6 to b5b0f69 Compare April 10, 2024 15:20

agg23 changed the base branch from main to libc-0.2 April 10, 2024 15:20

Ignore sockstat field on FreeBSD 15 CI

b5f85fc

madsmtm mentioned this pull request Apr 24, 2024

Add support for visionOS amodm/webbrowser-rs#86

Merged

JohnTitor approved these changes Apr 26, 2024

View reviewed changes

JohnTitor added this pull request to the merge queue Apr 26, 2024

Merged via the queue into rust-lang:libc-0.2 with commit eb1bad8 Apr 26, 2024
57 checks passed

tgross35 added the main-needs-cherry-pick This PR was merged against libc-0.2 but does not yet exist in main. label Aug 13, 2024

tgross35 pushed a commit to tgross35/rust-libc that referenced this pull request Aug 17, 2024

xrOS support

ec51515

Swapped to visionOS target_os (apply <rust-lang#3568> to `main`) [resolve conflicts - Trevor] (cherry picked from commit b5b0f69)

tgross35 mentioned this pull request Aug 17, 2024

[main] Apply two pull requests to main #3853

Merged

tgross35 pushed a commit to tgross35/rust-libc that referenced this pull request Aug 28, 2024

xrOS support

eff95d7

Swapped to visionOS target_os (apply <rust-lang#3568> to `main`) [ resolve conflicts - Trevor ] (cherry picked from commit b5b0f69)

tgross35 mentioned this pull request Aug 28, 2024

[main] Apply three pull requests to main #3872

Merged

tgross35 pushed a commit to tgross35/rust-libc that referenced this pull request Aug 28, 2024

xrOS support

484ebe8

Swapped to visionOS target_os (apply <rust-lang#3568> to `main`) [ resolve conflicts - Trevor ] (cherry picked from commit b5b0f69)

tgross35 pushed a commit to tgross35/rust-libc that referenced this pull request Aug 28, 2024

xrOS support

bfe4174

Swapped to visionOS target_os (apply <rust-lang#3568> to `main`) [ resolve conflicts - Trevor ] (cherry picked from commit b5b0f69)

tgross35 pushed a commit to tgross35/rust-libc that referenced this pull request Aug 28, 2024

xrOS support

41f7f37

Swapped to visionOS target_os (apply <rust-lang#3568> to `main`) [ resolve conflicts - Trevor ] (cherry picked from commit b5b0f69)

tgross35 added main-applied This PR was merged against libc-0.2 and main has since been updated to include it and removed main-needs-cherry-pick This PR was merged against libc-0.2 but does not yet exist in main. labels Aug 29, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

visionOS Support #3568

visionOS Support #3568

agg23 commented Jan 30, 2024

rustbot commented Jan 30, 2024

agg23 commented Jan 30, 2024

bors commented Feb 3, 2024

Urgau commented Feb 14, 2024 •

edited

Loading

JohnTitor commented Feb 25, 2024

QuentinPerez commented Mar 22, 2024

QuentinPerez commented Mar 31, 2024

agg23 commented Apr 6, 2024

madsmtm commented Apr 10, 2024

agg23 commented Apr 10, 2024

rudyrichter commented Apr 15, 2024

madsmtm commented Apr 18, 2024

agg23 commented Apr 18, 2024

rudyrichter commented Apr 19, 2024

coolbluewater commented Apr 26, 2024

JohnTitor commented Apr 26, 2024

coolbluewater commented Apr 27, 2024

madsmtm commented Apr 27, 2024

madsmtm commented Apr 30, 2024 •

edited

Loading

visionOS Support #3568

visionOS Support #3568

Conversation

agg23 commented Jan 30, 2024

rustbot commented Jan 30, 2024

agg23 commented Jan 30, 2024

bors commented Feb 3, 2024

Urgau commented Feb 14, 2024 • edited Loading

JohnTitor commented Feb 25, 2024

QuentinPerez commented Mar 22, 2024

QuentinPerez commented Mar 31, 2024

agg23 commented Apr 6, 2024

madsmtm commented Apr 10, 2024

agg23 commented Apr 10, 2024

rudyrichter commented Apr 15, 2024

madsmtm commented Apr 18, 2024

agg23 commented Apr 18, 2024

rudyrichter commented Apr 19, 2024

coolbluewater commented Apr 26, 2024

JohnTitor commented Apr 26, 2024

coolbluewater commented Apr 27, 2024

madsmtm commented Apr 27, 2024

madsmtm commented Apr 30, 2024 • edited Loading

Urgau commented Feb 14, 2024 •

edited

Loading

madsmtm commented Apr 30, 2024 •

edited

Loading