Add Nintendo Switch as tier 3 target #88991

jam1garner · 2021-09-15T21:42:28Z

This is the first step towards working on incrementally adding support for the Nintendo Switch. After this lands @leo60228 and I will work on ensuring further work is cleared from a legal perspective before continuing on to work on an allocator and porting libstd.

The plan is to keep these changes small and incremental enough so as to not cause unneeded burden on reviewers by submitting a single large patch, as was felt to be the case last attempt at upstreaming (#74567).

All this specific patch does is add the target itself without and std support, which has been tested on-device and is working as expected.

Designated Target Maintainers:

rust-highfive · 2021-09-15T21:42:31Z

r? @wesleywiser

(rust-highfive has picked a reviewer for you, use r? to override)

rust-highfive · 2021-09-15T21:42:31Z

⚠️ Warning ⚠️

These commits modify compiler targets. (See the Target Tier Policy.)

nagisa · 2021-09-15T21:49:51Z

Please copy the list of target requirements and verify all of the requirements are satisfied.

An example from one of the previous PRs: #88529 (comment)

compiler/rustc_target/src/spec/aarch64_nintendo_switch.rs

leo60228 · 2021-09-15T22:01:41Z

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.)

Yep, me and @jam1garner.

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.

We spent a good amount of time bikeshedding this, but aarch64-nintendo-switch is consistent with armv6k-nintendo-3ds and mipsel-sony-psp. One consideration was targets built on top of C libraries, but there's some precedent here for alternate versions of targets in the form of aarch64-apple-ios and aarch64-apple-ios-sim.

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 be subject to any new license requirements.

If the target supports building host tools (such as rustc or cargo), those host tools must not depend on proprietary (non-FOSS) libraries, other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. 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.

Targets should not require proprietary (non-FOSS) components to link a functional binary or library.

"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.

The code in this PR definitely shouldn't pose any issue. Before making PRs for libstd, we plan to consult the core team and foundation (as discussed on Zulip), but none of the explicitly mentioned issues apply.

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 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.

See discussion on Zulip. We're planning on adding support incrementally to make review easier for both ourselves and reviewers.

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 tests (even if they do not pass), the documentation must explain how to run tests for the target, using emulation if possible or dedicated hardware if necessary.

Currently, there's not much specific to the target. https://github.com/aarch64-switch-rs/cargo-nx works with --triple=aarch64-nintendo-switch.

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.

Assuming CI passes, I don't see any reason to think this would be an issue.

leo60228 · 2021-09-15T22:05:47Z

Also, for some relevant information that was posted on Zulip but wasn't copied here, this PR just adds a target definition. Future PRs for libstd will be pure Rust: we haven't signed any NDAs for the official SDK, and we don't plan to rely on unofficial C/C++ SDKs.

compiler/rustc_target/src/spec/aarch64_nintendo_switch_linker_script.ld

sgeos · 2021-09-16T10:52:17Z

If this is an NDA compliant port, please drop me a line on the English language official forums under "Off-Topic/Target Triple for Rust std" or "Off-Topic/Rust". If this is a homebrew initiative, an indication as such would be appreciated.

leo60228 · 2021-09-16T10:59:44Z

Also, for some relevant information that was posted on Zulip but wasn't copied here, this PR just adds a target definition. Future PRs for libstd will be pure Rust: we haven't signed any NDAs for the official SDK, and we don't plan to rely on unofficial C/C++ SDKs.

@sgeos Does this answer your question? I agree that this probably should've been in the PR description, but I didn't think of that while we were writing it and I can't edit it.

sgeos · 2021-09-16T11:01:32Z

Also, for some relevant information that was posted on Zulip but wasn't copied here, this PR just adds a target definition. Future PRs for libstd will be pure Rust: we haven't signed any NDAs for the official SDK, and we don't plan to rely on unofficial C/C++ SDKs.

@sgeos Does this answer your question? I agree that this probably should've been in the PR description, but I didn't think of that while we were writing it and I can't edit it.

The short answer is yes.

Aaron1011 · 2021-09-16T13:35:47Z

src/bootstrap/config.rs

@@ -308,7 +308,7 @@ pub struct Target {
 impl Target {
    pub fn from_triple(triple: &str) -> Self {
        let mut target: Self = Default::default();
-        if triple.contains("-none") || triple.contains("nvptx") {
+        if triple.contains("-none") || triple.contains("nvptx") || triple.contains("switch") {


Off topic - could this be turned into a no_std flag in the target config file?

The linker has the same issue with a FIXME for pulling the info from the target config file. I'm guessing that bootstrap doesn't have a way to access the actual target definition.

bootstrap could invoke rustc using --print cfg or something similar to print if the target is no_std if the target config file contains this. If it is a cfg, libstd could use the same cfg for restricted-std.

In this PR, though, it's just temporary until std is implemented on Switch.

leo60228 · 2021-09-16T14:06:33Z

For what it's worth, as a note on the naming, the Switch's operating system is a microkernel called Horizon. Horizon was also used on the 3DS, but it evolved quite a bit between the two consoles. aarch64-nintendo-horizon and aarch64-unknown-horizon were also considered, but with the acceptance of a 3DS target under the name armv6k-nintendo-3ds we decided to go with aarch64-nintendo-switch just for consistency.
One possible wrinkle here is that there are three projects reimplementing the Horizon microkernel:

mesosphere: complete C++ reimplementation targeting bug-for-bug compatibility, formally only supports the Switch but with a suitable bootloader could likely be ported to other Tegra X1 hardware with minimal changes to the kernel itself
SunriseOS: Rust reimplementation targeting i386, no longer developed (IIRC the authors were making it as part of an operating systems course, which has concluded)
Saturnus: early Rust reimplementation, I believe it currently targets the Switch but is planned to be a general-purpose RTOS

These projects might want to use the same target, in which case the aarch64-nintendo-switch name could be misleading. I'm not sure this is an actual issue, though, and I think consistency with the 3DS takes priority.

jam1garner · 2021-09-16T14:18:57Z

I think one relevant point about this being primarily designed for homebrew (I can't imagine an officially sanctioned game using this; if only because they need to dynamically link against the nnsdk), however we would like to keep the possibility for there to be another target designated for use when linking against the nnsdk. (an aarch64-nintendo-switch-nnsdk, if you will)

This is further complicated by the fact our plan for this target is to be a pure Rust toolchain (just interfacing with the syscall interface), which makes it a bit weird trying to specify a toolchain in the target. I think aarch64-nintendo-switch doesn't properly articulate it being for homebrew, but there isn't really a toolchain to append to it (like -musl on Linux targets). From a technical standpoint it makes sense as a 'default' as it's the least common denominator and would work in any context, but from a social standpoint much less so.

At risk of bikeshedding: If anyone has any thoughts on how this should be handled (even if just 'leave it alone'), I'd appreciate outside input

jam1garner · 2021-09-16T14:32:11Z

For what it's worth, as a note on the naming, the Switch's operating system is a microkernel called Horizon. Horizon was also used on the 3DS, but it evolved quite a bit between the two consoles. aarch64-nintendo-horizon and aarch64-unknown-horizon were also considered, but with the acceptance of a 3DS target under the name armv6k-nintendo-3ds we decided to go with aarch64-nintendo-switch just for consistency.
One possible wrinkle here is that there are three projects reimplementing the Horizon microkernel:
* [mesosphere](https://github.com/Atmosphere-NX/Atmosphere/tree/master/mesosphere): complete C++ reimplementation targeting bug-for-bug compatibility, formally only supports the Switch but with a suitable bootloader could likely be ported to other Tegra X1 hardware with minimal changes to the kernel itself

* [SunriseOS](https://github.com/sunriseos/SunriseOS): Rust reimplementation targeting i386, no longer developed (IIRC the authors were making it as part of an operating systems course, which has concluded)

* [Saturnus](https://github.com/vbe0201/Saturnus): early Rust reimplementation, I believe it currently targets the Switch but is planned to be a general-purpose RTOS
These projects might want to use the same target, in which case the aarch64-nintendo-switch name could be misleading. I'm not sure this is an actual issue, though, and I think consistency with the 3DS takes priority.

I think it's also worth noting that mesosphere is the only one out of the three currently 'production ready' (so to speak) and can for all intents and purposes be considered only for use on the switch, so I think actual room for confusion from 'switch' in the name to be nonexistant.

sgeos · 2021-09-17T01:43:20Z

I think one relevant point about this being primarily designed for homebrew (I can't imagine an officially sanctioned game using this; if only because they need to dynamically link against the nnsdk), however we would like to keep the possibility for there to be another target designated for use when linking against the nnsdk. (an aarch64-nintendo-switch-nnsdk, if you will)

This is further complicated by the fact our plan for this target is to be a pure Rust toolchain (just interfacing with the syscall interface), which makes it a bit weird trying to specify a toolchain in the target. I think aarch64-nintendo-switch doesn't properly articulate it being for homebrew, but there isn't really a toolchain to append to it (like -musl on Linux targets). From a technical standpoint it makes sense as a 'default' as it's the least common denominator and would work in any context, but from a social standpoint much less so.

At risk of bikeshedding: If anyone has any thoughts on how this should be handled (even if just 'leave it alone'), I'd appreciate outside input

aarch64-nintendo-switch does not conflict with any target triples that have been discussed behind the NDA wall, but it still might be confusing. aarch64-nintendo-switch-homebrew is entirely unambiguous. Personally, I would love to see a target that can be used for licensed commercial development. I am hoping this effort can be used as a basis for an official or semi-official target since you will probably move faster than me. Note that any such target, if created, will likely remain behind the NDA wall, probably forever.

jam1garner · 2021-09-17T03:17:22Z

Personally, I would love to see a target that can be used for licensed commercial development. I am hoping this effort can be used as a basis for an official or semi-official target since you will probably move faster than me. Note that any such target, if created, will likely remain behind the NDA wall, probably forever.

One thing I hope @sgeos (after further legal discussion, because I believe this will be an even more dicey endeavor than the currently proposed homebrew target) is that once further development is done on this target there could be a non-NDA'd target that would purely be based on the exposed symbols of the Nintendo SDK.

The reason I believe this could be possible is that (please note before I continue that I am not under a Nintendo NDA, have never looked upon or been given information covered by a Nintendo NDA, or otherwise interacted with NDA materials) the Nintendo SDK exports quite a large portion of libc required to produce a working Rust libstd.

I have experimented with this in the past for the purpose of modding games in the past (consider the fact that when modding games you are subject to a programming environment equivalent to that of the game, so a lot of this work could very well be helpful to a toolchain targetting 'official' game development).

I would believe that at minimum the subset of libc exported (sockets, pthreads, and a limited file API) would be enough to produce a semi-useful target without *any* copyrighted materials being involved (as, while I am not a lawyer and this is ofc not legal advice, I do not believe Nintendo has the rights to copyright a subset of libc :P )

As to whether or not such a target could dynamically link against other symbols in the nnsdk within libstd is less clear to me, however, but at minimum (a) skyline-rs/rust is a quite functional starting place for those under NDA making games if they would like a starting point and (b) I am willing to answer any questions about it people have (this is not the place to do so but it's not hard to find me elsewhere).

While working with the Rust Foundation and/or Rust core team when working on the homebrew libstd implementation I intend to also inquire about this. Hopefully there is a course of action I can take to enable development in the open but ultimately not putting the Rust project in legal jeopardy is my #1 priority for either of the proposed targets.

jam1garner · 2021-09-17T03:21:07Z

Also I should add that the current gameplan is that leo and I are currently assessing libstd implementation strategy and I plan on contacting both the foundation and the core team once both:

an implementation strategy is clear enough to present to legal and
this PR has merged

sgeos · 2021-09-17T11:09:27Z

Personally, I would love to see a target that can be used for licensed commercial development. I am hoping this effort can be used as a basis for an official or semi-official target since you will probably move faster than me. Note that any such target, if created, will likely remain behind the NDA wall, probably forever.

One thing I hope @sgeos (after further legal discussion, because I believe this will be an even more dicey endeavor than the currently proposed homebrew target) is that once further development is done on this target there could be a non-NDA'd target that would purely be based on the exposed symbols of the Nintendo SDK.

The reason I believe this could be possible is that (please note before I continue that I am not under a Nintendo NDA, have never looked upon or been given information covered by a Nintendo NDA, or otherwise interacted with NDA materials) the Nintendo SDK exports quite a large portion of libc required to produce a working Rust libstd.

I have experimented with this in the past for the purpose of modding games in the past (consider the fact that when modding games you are subject to a programming environment equivalent to that of the game, so a lot of this work could very well be helpful to a toolchain targetting 'official' game development).

I would believe that at minimum the subset of libc exported (sockets, pthreads, and a limited file API) would be enough to produce a semi-useful target without any copyrighted materials being involved (as, while I am not a lawyer and this is ofc not legal advice, I do not believe Nintendo has the rights to copyright a subset of libc :P )

As to whether or not such a target could dynamically link against other symbols in the nnsdk within libstd is less clear to me, however, but at minimum (a) skyline-rs/rust is a quite functional starting place for those under NDA making games if they would like a starting point and (b) I am willing to answer any questions about it people have (this is not the place to do so but it's not hard to find me elsewhere).

While working with the Rust Foundation and/or Rust core team when working on the homebrew libstd implementation I intend to also inquire about this. Hopefully there is a course of action I can take to enable development in the open but ultimately not putting the Rust project in legal jeopardy is my #1 priority for either of the proposed targets.

First of all, I am not an attorney. If you have legal concerns, it is a good idea to consult an attorney. Having said that, my understanding is that reverse engineering trade secrets is legal. Reverse engineering cannot be used as a defense for patent infringement, but there is precedent in the USA for interoperability and overturning silly patents.

The upshot is that reverse engineering whatever Nintendo is doing and implementing a target based on that knowledge is almost certainly legal, but there are a few things to be aware of. First of all, after signing an NDA and being approved as a developer, access to a lot of trade secret secrets is granted, technical and nontechnical. People who have signed such an NDA are obligated not to share these trade secrets even if they stop developing for the system. Anyone behind the NDA wall is legally unable to share trade secrets with you, but you are free to use publicly available information. I am pretty sure that leaks are public information that can be used, but I would double check this if it is important.

If someone who has signed an NDA feeds you information, that puts both you and that person at risk legally. I have seen projects roll back functionality that is based on propriety information. I think that this is a good idea if you get information that cannot be used legally. To the extent you have not signed an NDA, you are free to work and share information openly, but you may not make use of trade secrets provided by someone who has signed an NDA. Once you have signed an NDA, there is no going back, but people behind the NDA wall are free to use reverse engineered work, license permitting.

As far as concrete detail go, I do not see any problem building a target that relies on reverse engineered symbols that are present on the device. If you write a target that uses whatever subset of libc is exported, your aarch64 implementation may actually work on other aarch64 targets that export all of libc. Furthermore, it sounds like it might also work on the 3DS for the people who are still interested in developing homebrew for it. I think that working with the available reverse engineered libc symbols is the ideal strategy to use.

skade · 2021-09-17T12:10:30Z

@sgeos Thanks for the writeup and your view on this. I want to add another perspective though: whether something is legal or not is not the only concern. The problem is an intersection of the structure of the libc crate and legal interpretations. Because libc is one library spelling out all the targets, any action taken against one target - independent of the outcome - will impact all the others. That's the reason why we need to be careful and very solid in footing there. Every target needs to rely on our reading to be correct and when the reading includes external documents and agreements, it gets problematic.

That would be very different if a libc-switch crate existed and could be linked instead of the libc crate.

sgeos · 2021-09-17T12:42:09Z

@skade Thank you for the reply.

As far as external agreements go, my recommendation is to only allow people to contribute if A) they have no external agreements (NDA not signed, NDA trade secrets never seen, etc.), or B) they have explicit permission to contribute despite having signed an NDA. My understanding is that external documentation based on reverse engineering should be OK, but I honestly have no idea what the Switch homebrew community is using. Some of the other homebrew communities use extensive data sheets of technical information.

Does it make sense to create a libc-switch crate and conditionally link to it instead of the standard libc crate? If so, then the crate not existing is a solvable problem. Furthermore, implementing it may be an excellent strategy for approaching this kind of target. Worst case scenario, this libc-switch crate can simply be removed if unforeseeable problems emerge.

nagisa · 2021-09-17T13:04:03Z

I'm not sure we are in a position to verify that the contributors haven't signed some sort of an NDA, and drawing a line in the code for where such a verification should be made and where its not necessary seems infeasible at best.

Then again, adding a plain target dues not raise huge concerns here. Adding supporting code to libc/libstd seems like it would.

skade · 2021-09-17T13:07:38Z

@sgeos I'll write a full reply later, but just to make clear: the libc-switch crate was just a strawman, not a real idea and proposal. I just wanted to use it to illustrate how a separate scope may ease things.

leo60228 · 2021-09-17T13:31:37Z

My understanding is that external documentation based on reverse engineering should be OK, but I honestly have no idea what the Switch homebrew community is using. Some of the other homebrew communities use extensive data sheets of technical information.

Leaked materials definitely aren't used, though the public Tegra X1 TRM is frequently referenced for low-level details.

There's likely enough documentation for clean-room implementations, but if you consider having looked at any disassembly/decompilation to taint someone, you'll have a hard time finding developers. It's definitely a far better situation than the GameCube, where I've heard that chunks of the toolchain were directly taken from decompiler output...

For what it's worth, I think the fact that Nintendo hasn't taken action against Atmosphere (which has bug-compatible reimplementations of many system components) is good evidence that they wouldn't take action against a Rust port.

wesleywiser

Can you also add documentation for this target to src/doc/rustc/src/platform-support in the style of the existing iOS simulator docs?

leo60228 · 2021-09-17T14:03:49Z

@wesleywiser I was actually planning on doing that but I mistakenly thought those were in a separate repo, I'll write some.

leo60228 · 2021-09-17T14:14:22Z

For what it's worth, I'm open to a target name like aarch64-nintendo-switch-homebrew, but that feels way too long and I don't have any better ideas... It's also not especially descriptive: it could also be ambiguous with a theoretical libnx target.

wesleywiser · 2021-09-17T14:18:23Z

Also I should add that the current gameplan is that leo and I are currently assessing libstd implementation strategy and I plan on contacting both the foundation and the core team once both:

an implementation strategy is clear enough to present to legal and

this PR has merged

I think it would be helpful to go ahead and start this conversation now. From a technical perspective, the code here is fine and could be signed off on as it is. However, while it seems ok to me to merge this, I recognize that I am not a lawyer and don't really know what I'm talking about. 🙂

I would prefer if we had some kind of agreed upon strategy here for the target with those folks. If, for example, we could not find an implementation path that allows for in-tree libcore/libstd support for this target, that would place this target below Tier 3 support with no way to reach that level which seems undesirable long-term. In such a case, is having the target definition in-tree even useful? Hopefully, that is not the conclusion and we can provide robust support for the target but it would be good to clarify the situation at this time.

Edit: Upon a closer reading of the target tier RFC, it appears that Tier 3 support does not require libcore implemented so only having the target definition in-tree would technically qualify as Tier 3 support but that still doesn't seem like a desirable outcome.

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)

leo60228 · 2022-06-25T13:41:13Z

The 3DS target uses an existing C-based homebrew toolchain instead of talking directly to the system. That toolchain does have a Switch equivalent, but I would like to avoid that for several reasons (primary ones being a non-standard ABI requiring modifications to LLVM and the developers being actively hostile to its usage with non-C languages or non-GCC compilers).

…

On Sat, Jun 25, 2022, 4:46 AM Elias Gabriel Amaral da Silva < ***@***.***> wrote: I would prefer if we could have that comment from legal before proceeding. Is the specifics of this target substantially different from the 3ds target <https://doc.rust-lang.org/nightly/rustc/platform-support/armv6k-nintendo-3ds.html>? For example, are contributors to the armv6k-nintendo-3ds required to not have signed any NDA? And should the policy for this target be the same? — Reply to this email directly, view it on GitHub <#88991 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB7X32KMJAREUHPPTJARYJ3VQ3BM7ANCNFSM5EDLWRAA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

jam1garner · 2022-06-26T00:15:37Z

Additionally, the 3ds is EoL, the Switch is still actively sold. And another factor (echoing leo's sentiment but from a different angle) I think linking against a homebrew focused toolchain is likely a net negative for any use in published games (more applicable to a hypothetical nnsdk target, but also potentially applicable to a freestanding target).

I don't think there's actually any concern regarding the switch targets, just more things for project members and foundation legal to consider.

jam1garner · 2022-06-26T01:16:04Z

And @wesleywiser @nellshamrell any changes? I know @skade left the core team, is there anyone who was involved with the policy decision here that is still involved, or has this stalled and we need to find new project members to work with on this? Want to understand whether or not this is needing patience or finding new people within the rust project to discuss this with

nellshamrell · 2022-06-27T17:47:41Z

I will bring the legal question back to the Foundation. @wesleywiser do you know of any project specific concerns around this?

wesleywiser · 2022-07-14T18:54:26Z

@jam1garner thanks so much for your patience! I'm sorry it's taken this long to get an answer back to you.

Per our discussions with the Foundation's legal staff, we don't see an issue with merging this PR therefore:

@bors r+ rollup

bors · 2022-07-14T18:54:28Z

📌 Commit 29611d2ee50418a7f7149e33bd2e5445d29dbcd1 has been approved by wesleywiser

It is now in the queue for this repository.

I can't think of any other reason CI might be failing, and I should've done this anyway.

wesleywiser · 2022-07-14T21:18:58Z

Re-approving

@bors r+ rollup

bors · 2022-07-14T21:19:00Z

📌 Commit 62aafb0 has been approved by wesleywiser

It is now in the queue for this repository.

Rollup of 5 pull requests Successful merges: - rust-lang#88991 (Add Nintendo Switch as tier 3 target) - rust-lang#98869 (Remove some usages of `guess_head_span`) - rust-lang#99119 (Refactor: remove a string matching about methods) - rust-lang#99209 (Correctly handle crate level page on docs.rs as well) - rust-lang#99246 (Update RLS) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup

Pkgsrc changes: * Add patch to fix vendor/kqueue issue (on 32-bit hosts) * Adjust other patches & line numbers * Version bumps & checksum changes. Upstream changes: Version 1.64.0 (2022-09-22) =========================== Language -------- - [Unions with mutable references or tuples of allowed types are now allowed](rust-lang/rust#97995) - It is now considered valid to deallocate memory pointed to by a shared reference `&T` [if every byte in `T` is inside an `UnsafeCell`](rust-lang/rust#98017) - Unused tuple struct fields are now warned against in an allow-by-default lint, [`unused_tuple_struct_fields`] (rust-lang/rust#95977), similar to the existing warning for unused struct fields. This lint will become warn-by-default in the future. Compiler -------- - [Add Nintendo Switch as tier 3 target] (rust-lang/rust#88991) - Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. - [Only compile `#[used]` as llvm.compiler.used for ELF targets] (rust-lang/rust#93718) - [Add the `--diagnostic-width` compiler flag to define the terminal width.] (rust-lang/rust#95635) - [Add support for link-flavor `rust-lld` for iOS, tvOS and watchOS] (rust-lang/rust#98771) Libraries --------- - [Remove restrictions on compare-exchange memory ordering.] (rust-lang/rust#98383) - You can now `write!` or `writeln!` into an `OsString`: [Implement `fmt::Write` for `OsString`](rust-lang/rust#97915) - [Make RwLockReadGuard covariant] (rust-lang/rust#96820) - [Implement `FusedIterator` for `std::net::[Into]Incoming`] (rust-lang/rust#97300) - [`impl<T: AsRawFd> AsRawFd for {Arc,Box}<T>`] (rust-lang/rust#97437) - [`ptr::copy` and `ptr::swap` are doing untyped copies] (rust-lang/rust#97712) - [Add cgroupv1 support to `available_parallelism`] (rust-lang/rust#97925) - [Mitigate many incorrect uses of `mem::uninitialized`] (rust-lang/rust#99182) Stabilized APIs --------------- - [`future::IntoFuture`] (https://doc.rust-lang.org/stable/std/future/trait.IntoFuture.html) - [`future::poll_fn`] (https://doc.rust-lang.org/stable/std/future/fn.poll_fn.html) - [`task::ready!`] (https://doc.rust-lang.org/stable/std/task/macro.ready.html) - [`num::NonZero*::checked_mul`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroUsize.html#method.checked_mul) - [`num::NonZero*::checked_pow`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroUsize.html#method.checked_pow) - [`num::NonZero*::saturating_mul`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroUsize.html#method.saturating_mul) - [`num::NonZero*::saturating_pow`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroUsize.html#method.saturating_pow) - [`num::NonZeroI*::abs`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroIsize.html#method.abs) - [`num::NonZeroI*::checked_abs`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroIsize.html#method.checked_abs) - [`num::NonZeroI*::overflowing_abs`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroIsize.html#method.overflowing_abs) - [`num::NonZeroI*::saturating_abs`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroIsize.html#method.saturating_abs) - [`num::NonZeroI*::unsigned_abs`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroIsize.html#method.unsigned_abs) - [`num::NonZeroI*::wrapping_abs`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroIsize.html#method.wrapping_abs) - [`num::NonZeroU*::checked_add`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroUsize.html#method.checked_add) - [`num::NonZeroU*::checked_next_power_of_two`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroUsize.html#method.checked_next_power_of_two) - [`num::NonZeroU*::saturating_add`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroUsize.html#method.saturating_add) - [`os::unix::process::CommandExt::process_group`] (https://doc.rust-lang.org/stable/std/os/unix/process/trait.CommandExt.html#tymethod.process_group) - [`os::windows::fs::FileTypeExt::is_symlink_dir`] (https://doc.rust-lang.org/stable/std/os/windows/fs/trait.FileTypeExt.html#tymethod.is_symlink_dir) - [`os::windows::fs::FileTypeExt::is_symlink_file`] (https://doc.rust-lang.org/stable/std/os/windows/fs/trait.FileTypeExt.html#tymethod.is_symlink_file) These types were previously stable in `std::ffi`, but are now also available in `core` and `alloc`: - [`core::ffi::CStr`] (https://doc.rust-lang.org/stable/core/ffi/struct.CStr.html) - [`core::ffi::FromBytesWithNulError`] (https://doc.rust-lang.org/stable/core/ffi/struct.FromBytesWithNulError.html) - [`alloc::ffi::CString`] (https://doc.rust-lang.org/stable/alloc/ffi/struct.CString.html) - [`alloc::ffi::FromVecWithNulError`] (https://doc.rust-lang.org/stable/alloc/ffi/struct.FromVecWithNulError.html) - [`alloc::ffi::IntoStringError`] (https://doc.rust-lang.org/stable/alloc/ffi/struct.IntoStringError.html) - [`alloc::ffi::NulError`] (https://doc.rust-lang.org/stable/alloc/ffi/struct.NulError.html) These types were previously stable in `std::os::raw`, but are now also available in `core::ffi` and `std::ffi`: - [`ffi::c_char`] (https://doc.rust-lang.org/stable/std/ffi/type.c_char.html) - [`ffi::c_double`] (https://doc.rust-lang.org/stable/std/ffi/type.c_double.html) - [`ffi::c_float`] (https://doc.rust-lang.org/stable/std/ffi/type.c_float.html) - [`ffi::c_int`] (https://doc.rust-lang.org/stable/std/ffi/type.c_int.html) - [`ffi::c_long`] (https://doc.rust-lang.org/stable/std/ffi/type.c_long.html) - [`ffi::c_longlong`] (https://doc.rust-lang.org/stable/std/ffi/type.c_longlong.html) - [`ffi::c_schar`] (https://doc.rust-lang.org/stable/std/ffi/type.c_schar.html) - [`ffi::c_short`] (https://doc.rust-lang.org/stable/std/ffi/type.c_short.html) - [`ffi::c_uchar`] (https://doc.rust-lang.org/stable/std/ffi/type.c_uchar.html) - [`ffi::c_uint`] (https://doc.rust-lang.org/stable/std/ffi/type.c_uint.html) - [`ffi::c_ulong`] (https://doc.rust-lang.org/stable/std/ffi/type.c_ulong.html) - [`ffi::c_ulonglong`] (https://doc.rust-lang.org/stable/std/ffi/type.c_ulonglong.html) - [`ffi::c_ushort`] (https://doc.rust-lang.org/stable/std/ffi/type.c_ushort.html) These APIs are now usable in const contexts: - [`slice::from_raw_parts`] (https://doc.rust-lang.org/stable/core/slice/fn.from_raw_parts.html) Cargo ----- - [Packages can now inherit settings from the workspace so that the settings can be centralized in one place.] (rust-lang/cargo#10859) See [`workspace.package`](https://doc.rust-lang.org/nightly/cargo/reference/workspaces.html#the-workspacepackage-table) and [`workspace.dependencies`](https://doc.rust-lang.org/nightly/cargo/reference/workspaces.html#the-workspacedependencies-table) for more details on how to define these common settings. - [Cargo commands can now accept multiple `--target` flags to build for multiple targets at once] (rust-lang/cargo#10766), and the [`build.target`](https://doc.rust-lang.org/nightly/cargo/reference/config.html#buildtarget) config option may now take an array of multiple targets. - [The `--jobs` argument can now take a negative number to count backwards from the max CPUs.] (rust-lang/cargo#10844) - [`cargo add` will now update `Cargo.lock`.] (rust-lang/cargo#10902) - [Added](rust-lang/cargo#10838) the [`--crate-type`](https://doc.rust-lang.org/nightly/cargo/commands/cargo-rustc.html#option-cargo-rustc---crate-type) flag to `cargo rustc` to override the crate type. - [Significantly improved the performance fetching git dependencies from GitHub when using a hash in the `rev` field.] (rust-lang/cargo#10079) Misc ---- - [The `rust-analyzer` rustup component is now available on the stable channel.] (rust-lang/rust#98640) Compatibility Notes ------------------- - The minimum required versions for all `-linux-gnu` targets are now at least kernel 3.2 and glibc 2.17, for targets that previously supported older versions: [Increase the minimum linux-gnu versions](rust-lang/rust#95026) - [Network primitives are now implemented with the ideal Rust layout, not the C system layout] (rust-lang/rust#78802). This can cause problems when transmuting the types. - [Add assertion that `transmute_copy`'s `U` is not larger than `T`] (rust-lang/rust#98839) - [A soundness bug in `BTreeMap` was fixed] (rust-lang/rust#99413) that allowed data it was borrowing to be dropped before the container. - [The Drop behavior of C-like enums cast to ints has changed] (rust-lang/rust#96862). These are already discouraged by a compiler warning. - [Relate late-bound closure lifetimes to parent fn in NLL] (rust-lang/rust#98835) - [Errors at const-eval time are now in future incompatibility reports] (rust-lang/rust#97743) - On the `thumbv6m-none-eabi` target, some incorrect `asm!` statements were erroneously accepted if they used the high registers (r8 to r14) as an input/output operand. [This is no longer accepted] (rust-lang/rust#99155). - [`impl Trait` was accidentally accepted as the associated type value of return-position `impl Trait`] (rust-lang/rust#97346), without fulfilling all the trait bounds of that associated type, as long as the hidden type satisfies said bounds. This has been fixed. Internal Changes ---------------- These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools. - Windows builds now use profile-guided optimization, providing 10-20% improvements to compiler performance: [Utilize PGO for windows x64 rustc dist builds] (rust-lang/rust#96978) - [Stop keeping metadata in memory before writing it to disk] (rust-lang/rust#96544) - [compiletest: strip debuginfo by default for mode=ui] (rust-lang/rust#98140) - Many improvements to generated code for derives, including performance improvements: - [Don't use match-destructuring for derived ops on structs.] (rust-lang/rust#98446) - [Many small deriving cleanups] (rust-lang/rust#98741) - [More derive output improvements] (rust-lang/rust#98758) - [Clarify deriving code](rust-lang/rust#98915) - [Final derive output improvements] (rust-lang/rust#99046) - [Stop injecting `#[allow(unused_qualifications)]` in generated `derive` implementations](rust-lang/rust#99485) - [Improve `derive(Debug)`](rust-lang/rust#98190) - [Bump to clap 3](rust-lang/rust#98213) - [fully move dropck to mir](rust-lang/rust#98641) - [Optimize `Vec::insert` for the case where `index == len`.] (rust-lang/rust#98755) - [Convert rust-analyzer to an in-tree tool] (rust-lang/rust#99603)

Pkgsrc changes: * This package now contains rust-analyzer, so implicitly conflicts with that pkgsrc package. The same goes for the rust-src package. * Add NetBSD/arm6 port * Add unfinished NetBSD/mipsel port * Revert the use of the internal LLVM, should now build with the new pkgsrc LLVM (15). * Add depndence on compat80 for sparc64 to fix the build * Adapt patches * Add CHECK_INTERPRETER_SKIP for a few (mostly unused) files. (A proper fix may come later.) Upstream changes: Version 1.64.0 (2022-09-22) =========================== Language -------- - [Unions with mutable references or tuples of allowed types are now allowed](rust-lang/rust#97995) - It is now considered valid to deallocate memory pointed to by a shared reference `&T` [if every byte in `T` is inside an `UnsafeCell`](rust-lang/rust#98017) - Unused tuple struct fields are now warned against in an allow-by-default lint, [`unused_tuple_struct_fields`] (rust-lang/rust#95977), similar to the existing warning for unused struct fields. This lint will become warn-by-default in the future. Compiler -------- - [Add Nintendo Switch as tier 3 target] (rust-lang/rust#88991) - Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. - [Only compile `#[used]` as llvm.compiler.used for ELF targets] (rust-lang/rust#93718) - [Add the `--diagnostic-width` compiler flag to define the terminal width.] (rust-lang/rust#95635) - [Add support for link-flavor `rust-lld` for iOS, tvOS and watchOS] (rust-lang/rust#98771) Libraries --------- - [Remove restrictions on compare-exchange memory ordering.] (rust-lang/rust#98383) - You can now `write!` or `writeln!` into an `OsString`: [Implement `fmt::Write` for `OsString`](rust-lang/rust#97915) - [Make RwLockReadGuard covariant] (rust-lang/rust#96820) - [Implement `FusedIterator` for `std::net::[Into]Incoming`] (rust-lang/rust#97300) - [`impl<T: AsRawFd> AsRawFd for {Arc,Box}<T>`] (rust-lang/rust#97437) - [`ptr::copy` and `ptr::swap` are doing untyped copies] (rust-lang/rust#97712) - [Add cgroupv1 support to `available_parallelism`] (rust-lang/rust#97925) - [Mitigate many incorrect uses of `mem::uninitialized`] (rust-lang/rust#99182) Stabilized APIs --------------- - [`future::IntoFuture`] (https://doc.rust-lang.org/stable/std/future/trait.IntoFuture.html) - [`future::poll_fn`] (https://doc.rust-lang.org/stable/std/future/fn.poll_fn.html) - [`task::ready!`] (https://doc.rust-lang.org/stable/std/task/macro.ready.html) - [`num::NonZero*::checked_mul`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroUsize.html#method.checked_mul) - [`num::NonZero*::checked_pow`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroUsize.html#method.checked_pow) - [`num::NonZero*::saturating_mul`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroUsize.html#method.saturating_mul) - [`num::NonZero*::saturating_pow`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroUsize.html#method.saturating_pow) - [`num::NonZeroI*::abs`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroIsize.html#method.abs) - [`num::NonZeroI*::checked_abs`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroIsize.html#method.checked_abs) - [`num::NonZeroI*::overflowing_abs`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroIsize.html#method.overflowing_abs) - [`num::NonZeroI*::saturating_abs`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroIsize.html#method.saturating_abs) - [`num::NonZeroI*::unsigned_abs`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroIsize.html#method.unsigned_abs) - [`num::NonZeroI*::wrapping_abs`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroIsize.html#method.wrapping_abs) - [`num::NonZeroU*::checked_add`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroUsize.html#method.checked_add) - [`num::NonZeroU*::checked_next_power_of_two`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroUsize.html#method.checked_next_power_of_two) - [`num::NonZeroU*::saturating_add`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroUsize.html#method.saturating_add) - [`os::unix::process::CommandExt::process_group`] (https://doc.rust-lang.org/stable/std/os/unix/process/trait.CommandExt.html#tymethod.process_group) - [`os::windows::fs::FileTypeExt::is_symlink_dir`] (https://doc.rust-lang.org/stable/std/os/windows/fs/trait.FileTypeExt.html#tymethod.is_symlink_dir) - [`os::windows::fs::FileTypeExt::is_symlink_file`] (https://doc.rust-lang.org/stable/std/os/windows/fs/trait.FileTypeExt.html#tymethod.is_symlink_file) These types were previously stable in `std::ffi`, but are now also available in `core` and `alloc`: - [`core::ffi::CStr`] (https://doc.rust-lang.org/stable/core/ffi/struct.CStr.html) - [`core::ffi::FromBytesWithNulError`] (https://doc.rust-lang.org/stable/core/ffi/struct.FromBytesWithNulError.html) - [`alloc::ffi::CString`] (https://doc.rust-lang.org/stable/alloc/ffi/struct.CString.html) - [`alloc::ffi::FromVecWithNulError`] (https://doc.rust-lang.org/stable/alloc/ffi/struct.FromVecWithNulError.html) - [`alloc::ffi::IntoStringError`] (https://doc.rust-lang.org/stable/alloc/ffi/struct.IntoStringError.html) - [`alloc::ffi::NulError`] (https://doc.rust-lang.org/stable/alloc/ffi/struct.NulError.html) These types were previously stable in `std::os::raw`, but are now also available in `core::ffi` and `std::ffi`: - [`ffi::c_char`] (https://doc.rust-lang.org/stable/std/ffi/type.c_char.html) - [`ffi::c_double`] (https://doc.rust-lang.org/stable/std/ffi/type.c_double.html) - [`ffi::c_float`] (https://doc.rust-lang.org/stable/std/ffi/type.c_float.html) - [`ffi::c_int`] (https://doc.rust-lang.org/stable/std/ffi/type.c_int.html) - [`ffi::c_long`] (https://doc.rust-lang.org/stable/std/ffi/type.c_long.html) - [`ffi::c_longlong`] (https://doc.rust-lang.org/stable/std/ffi/type.c_longlong.html) - [`ffi::c_schar`] (https://doc.rust-lang.org/stable/std/ffi/type.c_schar.html) - [`ffi::c_short`] (https://doc.rust-lang.org/stable/std/ffi/type.c_short.html) - [`ffi::c_uchar`] (https://doc.rust-lang.org/stable/std/ffi/type.c_uchar.html) - [`ffi::c_uint`] (https://doc.rust-lang.org/stable/std/ffi/type.c_uint.html) - [`ffi::c_ulong`] (https://doc.rust-lang.org/stable/std/ffi/type.c_ulong.html) - [`ffi::c_ulonglong`] (https://doc.rust-lang.org/stable/std/ffi/type.c_ulonglong.html) - [`ffi::c_ushort`] (https://doc.rust-lang.org/stable/std/ffi/type.c_ushort.html) These APIs are now usable in const contexts: - [`slice::from_raw_parts`] (https://doc.rust-lang.org/stable/core/slice/fn.from_raw_parts.html) Cargo ----- - [Packages can now inherit settings from the workspace so that the settings can be centralized in one place.] (rust-lang/cargo#10859) See [`workspace.package`](https://doc.rust-lang.org/nightly/cargo/reference/workspaces.html#the-workspacepackage-table) and [`workspace.dependencies`](https://doc.rust-lang.org/nightly/cargo/reference/workspaces.html#the-workspacedependencies-table) for more details on how to define these common settings. - [Cargo commands can now accept multiple `--target` flags to build for multiple targets at once] (rust-lang/cargo#10766), and the [`build.target`](https://doc.rust-lang.org/nightly/cargo/reference/config.html#buildtarget) config option may now take an array of multiple targets. - [The `--jobs` argument can now take a negative number to count backwards from the max CPUs.] (rust-lang/cargo#10844) - [`cargo add` will now update `Cargo.lock`.] (rust-lang/cargo#10902) - [Added](rust-lang/cargo#10838) the [`--crate-type`](https://doc.rust-lang.org/nightly/cargo/commands/cargo-rustc.html#option-cargo-rustc---crate-type) flag to `cargo rustc` to override the crate type. - [Significantly improved the performance fetching git dependencies from GitHub when using a hash in the `rev` field.] (rust-lang/cargo#10079) Misc ---- - [The `rust-analyzer` rustup component is now available on the stable channel.] (rust-lang/rust#98640) Compatibility Notes ------------------- - The minimum required versions for all `-linux-gnu` targets are now at least kernel 3.2 and glibc 2.17, for targets that previously supported older versions: [Increase the minimum linux-gnu versions](rust-lang/rust#95026) - [Network primitives are now implemented with the ideal Rust layout, not the C system layout] (rust-lang/rust#78802). This can cause problems when transmuting the types. - [Add assertion that `transmute_copy`'s `U` is not larger than `T`] (rust-lang/rust#98839) - [A soundness bug in `BTreeMap` was fixed] (rust-lang/rust#99413) that allowed data it was borrowing to be dropped before the container. - [The Drop behavior of C-like enums cast to ints has changed] (rust-lang/rust#96862). These are already discouraged by a compiler warning. - [Relate late-bound closure lifetimes to parent fn in NLL] (rust-lang/rust#98835) - [Errors at const-eval time are now in future incompatibility reports] (rust-lang/rust#97743) - On the `thumbv6m-none-eabi` target, some incorrect `asm!` statements were erroneously accepted if they used the high registers (r8 to r14) as an input/output operand. [This is no longer accepted] (rust-lang/rust#99155). - [`impl Trait` was accidentally accepted as the associated type value of return-position `impl Trait`] (rust-lang/rust#97346), without fulfilling all the trait bounds of that associated type, as long as the hidden type satisfies said bounds. This has been fixed. Internal Changes ---------------- These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools. - Windows builds now use profile-guided optimization, providing 10-20% improvements to compiler performance: [Utilize PGO for windows x64 rustc dist builds] (rust-lang/rust#96978) - [Stop keeping metadata in memory before writing it to disk] (rust-lang/rust#96544) - [compiletest: strip debuginfo by default for mode=ui] (rust-lang/rust#98140) - Many improvements to generated code for derives, including performance improvements: - [Don't use match-destructuring for derived ops on structs.] (rust-lang/rust#98446) - [Many small deriving cleanups] (rust-lang/rust#98741) - [More derive output improvements] (rust-lang/rust#98758) - [Clarify deriving code](rust-lang/rust#98915) - [Final derive output improvements] (rust-lang/rust#99046) - [Stop injecting `#[allow(unused_qualifications)]` in generated `derive` implementations](rust-lang/rust#99485) - [Improve `derive(Debug)`](rust-lang/rust#98190) - [Bump to clap 3](rust-lang/rust#98213) - [fully move dropck to mir](rust-lang/rust#98641) - [Optimize `Vec::insert` for the case where `index == len`.] (rust-lang/rust#98755) - [Convert rust-analyzer to an in-tree tool] (rust-lang/rust#99603)

rust-highfive assigned wesleywiser Sep 15, 2021

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 15, 2021

petrochenkov reviewed Sep 15, 2021

View reviewed changes

compiler/rustc_target/src/spec/aarch64_nintendo_switch.rs Outdated Show resolved Hide resolved

bjorn3 reviewed Sep 15, 2021

View reviewed changes

compiler/rustc_target/src/spec/aarch64_nintendo_switch_linker_script.ld Outdated Show resolved Hide resolved

ozkriff mentioned this pull request Sep 16, 2021

Rust on Consoles rust-gamedev/wg#90

Open

Aaron1011 reviewed Sep 16, 2021

View reviewed changes

wesleywiser requested changes Sep 17, 2021

View reviewed changes

wesleywiser approved these changes Jul 14, 2022

View reviewed changes

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-blocked Status: Blocked on something else such as an RFC or other implementation work. labels Jul 14, 2022

jam1garner and others added 10 commits July 14, 2022 15:55

Add Nintendo Switch tier 3 target

e6aedf6

Don't use host linker for switch

60beb1a

Remove unnecessary linker args

f688a56

Add linker script for switch

4bc8549

Don't build std for switch

bee373c

Remove unneeded options from Nintendo Switch target

7f88049

Remove obsolete crt0 references in linker script

c690db4

Add docs for Switch target

fd81b99

Add aarch64-nintendo-switch.md to SUMMARY.md

d04753e

I can't think of any other reason CI might be failing, and I should've done this anyway.

Rename aarch64-nintendo-switch to aarch64-nintendo-switch-freestanding

62aafb0

leo60228 force-pushed the aarch64-nintendo-switch branch from 29611d2 to 62aafb0 Compare July 14, 2022 20:02

rustbot added the T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) label Jul 14, 2022

Dylan-DPC mentioned this pull request Jul 15, 2022

Rollup of 5 pull requests #99278

Merged

bors merged commit a6d3ee3 into rust-lang:master Jul 15, 2022

rustbot added this to the 1.64.0 milestone Jul 15, 2022

GnomedDev mentioned this pull request Sep 25, 2022

Move to using the tier 3 target aarch64-switch-rs/cargo-nx#6

Closed

Add Nintendo Switch as tier 3 target #88991

Add Nintendo Switch as tier 3 target #88991

Conversation

jam1garner commented Sep 15, 2021 • edited Loading

rust-highfive commented Sep 15, 2021

rust-highfive commented Sep 15, 2021

nagisa commented Sep 15, 2021

leo60228 commented Sep 15, 2021 • edited Loading

leo60228 commented Sep 15, 2021

sgeos commented Sep 16, 2021

leo60228 commented Sep 16, 2021

sgeos commented Sep 16, 2021

Aaron1011 Sep 16, 2021

Choose a reason for hiding this comment

leo60228 Sep 16, 2021

Choose a reason for hiding this comment

bjorn3 Jul 14, 2022

Choose a reason for hiding this comment

leo60228 Jul 14, 2022

Choose a reason for hiding this comment

leo60228 commented Sep 16, 2021

jam1garner commented Sep 16, 2021

jam1garner commented Sep 16, 2021

sgeos commented Sep 17, 2021 • edited Loading

jam1garner commented Sep 17, 2021 • edited Loading

jam1garner commented Sep 17, 2021

sgeos commented Sep 17, 2021 • edited Loading

skade commented Sep 17, 2021 • edited Loading

sgeos commented Sep 17, 2021 • edited Loading

nagisa commented Sep 17, 2021 • edited Loading

skade commented Sep 17, 2021

leo60228 commented Sep 17, 2021

wesleywiser left a comment • edited Loading

Choose a reason for hiding this comment

leo60228 commented Sep 17, 2021

leo60228 commented Sep 17, 2021

wesleywiser commented Sep 17, 2021 • edited Loading

leo60228 commented Jun 25, 2022 via email

jam1garner commented Jun 26, 2022

jam1garner commented Jun 26, 2022

nellshamrell commented Jun 27, 2022

wesleywiser commented Jul 14, 2022

bors commented Jul 14, 2022

wesleywiser commented Jul 14, 2022

bors commented Jul 14, 2022

jam1garner commented Sep 15, 2021 •

edited

Loading

leo60228 commented Sep 15, 2021 •

edited

Loading

sgeos commented Sep 17, 2021 •

edited

Loading

jam1garner commented Sep 17, 2021 •

edited

Loading

sgeos commented Sep 17, 2021 •

edited

Loading

skade commented Sep 17, 2021 •

edited

Loading

sgeos commented Sep 17, 2021 •

edited

Loading

nagisa commented Sep 17, 2021 •

edited

Loading

wesleywiser left a comment •

edited

Loading

wesleywiser commented Sep 17, 2021 •

edited

Loading