Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add target support for RTEMS Arm #127021

Conversation

thesummer
Copy link
Contributor

@thesummer thesummer commented Jun 27, 2024

armv7-rtems-eabihf

This PR adds a new target for the RTEMS RTOS. To get things started it focuses on Xilinx/AMD Zynq-based targets, but in theory it should also support other armv7-based board support packages in the future.
Given that RTEMS has support for many POSIX functions it is mostly enabling corresponding unix features for the new target.
I also previously started a PR in libc (rust-lang/libc#3866) to add the needed OS specific C-bindings and was told that a PR in this repo is needed first. I will update the PR to the newest version after approval here.
I will probably also need to change one line in the backtrace repo.

Current status is that I could compile rustc for the new target locally (with the updated libc and backtrace) and could compile binaries, link, and execute a simple "Hello World" RTEMS application for the target hardware.

A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance.

There should be no breaking changes for existing targets. Main changes are adding corresponding cfg switches for the RTEMS OS and adding the C binding in libc.

Tier 3 target policy

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

I will do the maintenance (for now) further members of the RTEMS community will most likely join once the first steps have been done.

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

The proposed triple is armv7-rtems-eabihf

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

The tools consists of the cross-compiler toolchain (gcc-based). The RTEMS kernel (BSD license) and parts of the driver stack of FreeBSD (BSD license). All tools are FOSS and publicly available here: https://gitlab.rtems.org/rtems
There are also no new features or dependencies introduced to the Rust code.

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

N/A to me. I am not a reviewer nor Rust team member.

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

core and std compile. Some advanced features of the std lib might not work yet. However, the goal of this tier 3 target it to make it easier for other people to build and run test applications to better identify the unsupported features and work towards enabling them.

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

Building is described in platform support doc. Running simple unit tests works. Running the test suite of the stdlib is currently not that easy. Trying to work towards that after the this target has been added to the nightly.

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

Understood.

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

Ok

  • 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 think, I didn't add any breaking changes for any existing targets (see the comment regarding features above).

  • Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target.

Can produce assembly code via the llvm backend (tested on Linux).

If a tier 3 target stops meeting these requirements, or the target maintainers no longer have interest or time, or the target shows no signs of activity and has not built for some time, or removing the target would improve the quality of the Rust codebase, we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target), to check potential interest in improving the situation.GIAt this tier, the Rust project provides no official support for a target, so we place minimal requirements on the introduction of targets.

Understood.

r? compiler-team

@rustbot
Copy link
Collaborator

rustbot commented Jun 27, 2024

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @compiler-errors (or someone else) some time within the next two weeks.

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

@rustbot rustbot added O-unix Operating system: Unix-like S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jun 27, 2024
@rustbot
Copy link
Collaborator

rustbot commented Jun 27, 2024

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

Some changes occurred in src/doc/rustc/src/platform-support

cc @Nilstrieb

@rust-log-analyzer

This comment has been minimized.

Cargo.toml Outdated Show resolved Hide resolved
@thesummer thesummer force-pushed the 1-add-target-support-for-rtems-arm-xilinx-zedboard branch from 258ff09 to 792a693 Compare June 27, 2024 07:36
@rust-log-analyzer

This comment has been minimized.

@workingjubilee
Copy link
Member

workingjubilee commented Jun 27, 2024

./x.py --bless ./x.py test --bless (whups) should solve the last test issue.

@rustbot
Copy link
Collaborator

rustbot commented Jun 27, 2024

Some changes occurred in tests/ui/check-cfg

cc @Urgau

@rust-log-analyzer

This comment has been minimized.

@thesummer thesummer force-pushed the 1-add-target-support-for-rtems-arm-xilinx-zedboard branch from 99800ab to 21d16e6 Compare June 27, 2024 08:48
@rust-log-analyzer

This comment has been minimized.

@thesummer thesummer force-pushed the 1-add-target-support-for-rtems-arm-xilinx-zedboard branch from 21d16e6 to 692c9e5 Compare June 27, 2024 11:31
@rust-log-analyzer

This comment has been minimized.

@thesummer thesummer force-pushed the 1-add-target-support-for-rtems-arm-xilinx-zedboard branch 3 times, most recently from 0449b07 to 3a1a4dc Compare June 27, 2024 13:29
@thesummer
Copy link
Contributor Author

Pipeline works now 🎉 . Also rebased to current master.

@thesummer thesummer requested a review from jfrimmel June 28, 2024 07:49
@bors
Copy link
Contributor

bors commented Jul 1, 2024

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

@thesummer thesummer force-pushed the 1-add-target-support-for-rtems-arm-xilinx-zedboard branch 2 times, most recently from bbecec5 to deeceb5 Compare July 1, 2024 14:48
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@thesummer thesummer force-pushed the 1-add-target-support-for-rtems-arm-xilinx-zedboard branch from 7708f68 to 6fd358e Compare September 3, 2024 07:23
@thesummer
Copy link
Contributor Author

@tgross35 I rebased again and fixed the error. Could you please add the PR to the queue again?

@thesummer
Copy link
Contributor Author

@rustbot label -S-waiting-on-author S-waiting-on-review

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 3, 2024
@tgross35
Copy link
Contributor

tgross35 commented Sep 3, 2024

@bors r

For future reference, @rustbot review changes the label from author to review in one step

@bors
Copy link
Contributor

bors commented Sep 3, 2024

📌 Commit 6fd358e has been approved by tgross35

It is now in the queue for this repository.

@bors 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-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 3, 2024
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Sep 3, 2024
…-rtems-arm-xilinx-zedboard, r=tgross35

Add target support for RTEMS Arm

# `armv7-rtems-eabihf`

This PR adds a new target for the RTEMS RTOS. To get things started it focuses on Xilinx/AMD Zynq-based targets, but in theory it should also support other armv7-based board support packages in the future.
Given that RTEMS has support for many POSIX functions it is mostly enabling corresponding unix features for the new target.
I also previously started a PR in libc (rust-lang/libc#3561) to add the needed OS specific C-bindings and was told that a PR in this repo is needed first. I will update the PR to the newest version after approval here.
I will probably also need to change one line in the backtrace repo.

Current status is that I could compile rustc for the new target locally (with the updated libc and backtrace) and could compile binaries, link, and execute a simple "Hello World" RTEMS application for the target hardware.

> A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance.

There should be no breaking changes for existing targets. Main changes are adding corresponding `cfg` switches for the RTEMS OS and adding the C binding in libc.

# Tier 3 target policy

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

I will do the maintenance (for now) further members of the RTEMS community will most likely join once the first steps have been done.

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

The proposed triple is `armv7-rtems-eabihf`

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

The tools consists of the cross-compiler toolchain (gcc-based). The RTEMS kernel (BSD license) and parts of the driver stack of FreeBSD (BSD license). All tools are FOSS and publicly available here: https://gitlab.rtems.org/rtems
There are also no new features or dependencies introduced to the Rust code.

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

N/A to me. I am not a reviewer nor Rust team member.

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

`core` and `std` compile. Some advanced features of the `std` lib might not work yet. However, the goal of this tier 3 target it to make it easier for other people to build and run test applications to better identify the unsupported features and work towards enabling them.

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

Building is described in platform support doc. Running simple unit tests works. Running the test suite of the stdlib is currently not that easy. Trying to work towards that after the this target has been added to the nightly.

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

Understood.

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

Ok

> - 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 think, I didn't add any breaking changes for any existing targets (see the comment regarding features above).

> - Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target.

Can produce assembly code via the llvm backend (tested on Linux).

>
> If a tier 3 target stops meeting these requirements, or the target maintainers no longer have interest or time, or the target shows no signs of activity and has not built for some time, or removing the target would improve the quality of the Rust codebase, we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target), to check potential interest in improving the situation.GIAt this tier, the Rust project provides no official support for a target, so we place minimal requirements on the introduction of targets.

Understood.

r? compiler-team
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 3, 2024
…llaumeGomez

Rollup of 7 pull requests

Successful merges:

 - rust-lang#127021 (Add target support for RTEMS Arm)
 - rust-lang#128871 (bypass linker configuration and cross target check for specific commands)
 - rust-lang#129471 ([rustdoc] Sort impl associated items by kinds and then by appearance)
 - rust-lang#129529 (Add test to build crates used by r-a on stable)
 - rust-lang#129706 (Rename dump of coroutine by-move-body to be more consistent, fix ICE in dump_mir)
 - rust-lang#129796 (Unify scraped examples with other code examples)
 - rust-lang#129939 (explain why Rvalue::Len still exists)

r? `@ghost`
`@rustbot` modify labels: rollup
tgross35 added a commit to tgross35/rust that referenced this pull request Sep 4, 2024
…-rtems-arm-xilinx-zedboard, r=tgross35

Add target support for RTEMS Arm

# `armv7-rtems-eabihf`

This PR adds a new target for the RTEMS RTOS. To get things started it focuses on Xilinx/AMD Zynq-based targets, but in theory it should also support other armv7-based board support packages in the future.
Given that RTEMS has support for many POSIX functions it is mostly enabling corresponding unix features for the new target.
I also previously started a PR in libc (rust-lang/libc#3561) to add the needed OS specific C-bindings and was told that a PR in this repo is needed first. I will update the PR to the newest version after approval here.
I will probably also need to change one line in the backtrace repo.

Current status is that I could compile rustc for the new target locally (with the updated libc and backtrace) and could compile binaries, link, and execute a simple "Hello World" RTEMS application for the target hardware.

> A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance.

There should be no breaking changes for existing targets. Main changes are adding corresponding `cfg` switches for the RTEMS OS and adding the C binding in libc.

# Tier 3 target policy

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

I will do the maintenance (for now) further members of the RTEMS community will most likely join once the first steps have been done.

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

The proposed triple is `armv7-rtems-eabihf`

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

The tools consists of the cross-compiler toolchain (gcc-based). The RTEMS kernel (BSD license) and parts of the driver stack of FreeBSD (BSD license). All tools are FOSS and publicly available here: https://gitlab.rtems.org/rtems
There are also no new features or dependencies introduced to the Rust code.

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

N/A to me. I am not a reviewer nor Rust team member.

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

`core` and `std` compile. Some advanced features of the `std` lib might not work yet. However, the goal of this tier 3 target it to make it easier for other people to build and run test applications to better identify the unsupported features and work towards enabling them.

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

Building is described in platform support doc. Running simple unit tests works. Running the test suite of the stdlib is currently not that easy. Trying to work towards that after the this target has been added to the nightly.

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

Understood.

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

Ok

> - 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 think, I didn't add any breaking changes for any existing targets (see the comment regarding features above).

> - Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target.

Can produce assembly code via the llvm backend (tested on Linux).

>
> If a tier 3 target stops meeting these requirements, or the target maintainers no longer have interest or time, or the target shows no signs of activity and has not built for some time, or removing the target would improve the quality of the Rust codebase, we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target), to check potential interest in improving the situation.GIAt this tier, the Rust project provides no official support for a target, so we place minimal requirements on the introduction of targets.

Understood.

r? compiler-team
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 4, 2024
Rollup of 8 pull requests

Successful merges:

 - rust-lang#101339 (enable -Zrandomize-layout in debug CI builds )
 - rust-lang#127021 (Add target support for RTEMS Arm)
 - rust-lang#128871 (bypass linker configuration and cross target check for specific commands)
 - rust-lang#129471 ([rustdoc] Sort impl associated items by kinds and then by appearance)
 - rust-lang#129529 (Add test to build crates used by r-a on stable)
 - rust-lang#129624 (Adjust `memchr` pinning and run `cargo update`)
 - rust-lang#129796 (Unify scraped examples with other code examples)
 - rust-lang#129939 (explain why Rvalue::Len still exists)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 4, 2024
Rollup of 8 pull requests

Successful merges:

 - rust-lang#101339 (enable -Zrandomize-layout in debug CI builds )
 - rust-lang#127021 (Add target support for RTEMS Arm)
 - rust-lang#128871 (bypass linker configuration and cross target check for specific commands)
 - rust-lang#129471 ([rustdoc] Sort impl associated items by kinds and then by appearance)
 - rust-lang#129529 (Add test to build crates used by r-a on stable)
 - rust-lang#129624 (Adjust `memchr` pinning and run `cargo update`)
 - rust-lang#129796 (Unify scraped examples with other code examples)
 - rust-lang#129939 (explain why Rvalue::Len still exists)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 4, 2024
Rollup of 8 pull requests

Successful merges:

 - rust-lang#101339 (enable -Zrandomize-layout in debug CI builds )
 - rust-lang#127021 (Add target support for RTEMS Arm)
 - rust-lang#128871 (bypass linker configuration and cross target check for specific commands)
 - rust-lang#129471 ([rustdoc] Sort impl associated items by kinds and then by appearance)
 - rust-lang#129529 (Add test to build crates used by r-a on stable)
 - rust-lang#129624 (Adjust `memchr` pinning and run `cargo update`)
 - rust-lang#129796 (Unify scraped examples with other code examples)
 - rust-lang#129939 (explain why Rvalue::Len still exists)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 5, 2024
Rollup of 8 pull requests

Successful merges:

 - rust-lang#101339 (enable -Zrandomize-layout in debug CI builds )
 - rust-lang#127021 (Add target support for RTEMS Arm)
 - rust-lang#128871 (bypass linker configuration and cross target check for specific commands)
 - rust-lang#129471 ([rustdoc] Sort impl associated items by kinds and then by appearance)
 - rust-lang#129529 (Add test to build crates used by r-a on stable)
 - rust-lang#129624 (Adjust `memchr` pinning and run `cargo update`)
 - rust-lang#129796 (Unify scraped examples with other code examples)
 - rust-lang#129939 (explain why Rvalue::Len still exists)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 5, 2024
…iaskrgr

Rollup of 10 pull requests

Successful merges:

 - rust-lang#101339 (enable -Zrandomize-layout in debug CI builds )
 - rust-lang#120736 (rustdoc: add header map to the table of contents)
 - rust-lang#127021 (Add target support for RTEMS Arm)
 - rust-lang#128928 (CI: rfl: add more tools and steps)
 - rust-lang#129584 (warn the user if the upstream master branch is old)
 - rust-lang#129664 (Arbitrary self types v2: pointers feature gate.)
 - rust-lang#129752 (Make supertrait and implied predicates queries defaulted)
 - rust-lang#129918 (Update docs of `missing_abi` lint)
 - rust-lang#129919 (Stabilize `waker_getters`)
 - rust-lang#129925 (remove deprecated option `rust.split-debuginfo`)

Failed merges:

 - rust-lang#129789 (rustdoc: use strategic boxing to shrink `clean::Item`)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 5, 2024
…iaskrgr

Rollup of 10 pull requests

Successful merges:

 - rust-lang#101339 (enable -Zrandomize-layout in debug CI builds )
 - rust-lang#120736 (rustdoc: add header map to the table of contents)
 - rust-lang#127021 (Add target support for RTEMS Arm)
 - rust-lang#128928 (CI: rfl: add more tools and steps)
 - rust-lang#129584 (warn the user if the upstream master branch is old)
 - rust-lang#129664 (Arbitrary self types v2: pointers feature gate.)
 - rust-lang#129752 (Make supertrait and implied predicates queries defaulted)
 - rust-lang#129918 (Update docs of `missing_abi` lint)
 - rust-lang#129919 (Stabilize `waker_getters`)
 - rust-lang#129925 (remove deprecated option `rust.split-debuginfo`)

Failed merges:

 - rust-lang#129789 (rustdoc: use strategic boxing to shrink `clean::Item`)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 3775e6b into rust-lang:master Sep 5, 2024
6 checks passed
@rustbot rustbot added this to the 1.83.0 milestone Sep 5, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Sep 5, 2024
Rollup merge of rust-lang#127021 - thesummer:1-add-target-support-for-rtems-arm-xilinx-zedboard, r=tgross35

Add target support for RTEMS Arm

# `armv7-rtems-eabihf`

This PR adds a new target for the RTEMS RTOS. To get things started it focuses on Xilinx/AMD Zynq-based targets, but in theory it should also support other armv7-based board support packages in the future.
Given that RTEMS has support for many POSIX functions it is mostly enabling corresponding unix features for the new target.
I also previously started a PR in libc (rust-lang/libc#3561) to add the needed OS specific C-bindings and was told that a PR in this repo is needed first. I will update the PR to the newest version after approval here.
I will probably also need to change one line in the backtrace repo.

Current status is that I could compile rustc for the new target locally (with the updated libc and backtrace) and could compile binaries, link, and execute a simple "Hello World" RTEMS application for the target hardware.

> A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance.

There should be no breaking changes for existing targets. Main changes are adding corresponding `cfg` switches for the RTEMS OS and adding the C binding in libc.

# Tier 3 target policy

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

I will do the maintenance (for now) further members of the RTEMS community will most likely join once the first steps have been done.

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

The proposed triple is `armv7-rtems-eabihf`

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

The tools consists of the cross-compiler toolchain (gcc-based). The RTEMS kernel (BSD license) and parts of the driver stack of FreeBSD (BSD license). All tools are FOSS and publicly available here: https://gitlab.rtems.org/rtems
There are also no new features or dependencies introduced to the Rust code.

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

N/A to me. I am not a reviewer nor Rust team member.

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

`core` and `std` compile. Some advanced features of the `std` lib might not work yet. However, the goal of this tier 3 target it to make it easier for other people to build and run test applications to better identify the unsupported features and work towards enabling them.

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

Building is described in platform support doc. Running simple unit tests works. Running the test suite of the stdlib is currently not that easy. Trying to work towards that after the this target has been added to the nightly.

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

Understood.

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

Ok

> - 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 think, I didn't add any breaking changes for any existing targets (see the comment regarding features above).

> - Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target.

Can produce assembly code via the llvm backend (tested on Linux).

>
> If a tier 3 target stops meeting these requirements, or the target maintainers no longer have interest or time, or the target shows no signs of activity and has not built for some time, or removing the target would improve the quality of the Rust codebase, we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target), to check potential interest in improving the situation.GIAt this tier, the Rust project provides no official support for a target, so we place minimal requirements on the introduction of targets.

Understood.

r? compiler-team
workingjubilee pushed a commit to rust-lang/backtrace-rs that referenced this pull request Sep 7, 2024
We added target support for RTEMS OS in rust-lang/rust#127021

It has a POSIX interface, so we could reuse much of the `unix` backend, but
currently libunwind is not supported.

Add a `cfg` switch to disable libunwind for RTEMS.
carolynzech added a commit to carolynzech/verify-rust-std that referenced this pull request Sep 9, 2024
4f47132d7d3 Auto merge of rust-lang#129941 - BoxyUwU:bump-boostrap, r=albertlarsan68
fd0bc94d539 Adjust doc comment of Condvar::wait_while
2699de648cc Rollup merge of rust-lang#129963 - rjooske:fix/inaccurate_to_string_lossy_doc, r=workingjubilee
cde81452601 Auto merge of rust-lang#129999 - matthiaskrgr:rollup-pzr9c8p, r=matthiaskrgr
ab4b4f8c12e Rollup merge of rust-lang#129947 - LiterallyVoid:duration-docs-digit-separators, r=tgross35
3e7e6cdbd64 Rollup merge of rust-lang#129653 - RalfJung:addr-of-read-only, r=scottmcm
e51a0bc9ea0 Rollup merge of rust-lang#129938 - chancancode:patch-1, r=thomcc
349f8d57256 update cfgs
181dc2674a5 Rollup merge of rust-lang#129919 - kevinmehall:waker-getters, r=dtolnay
3d2a91f59a9 Rollup merge of rust-lang#127021 - thesummer:1-add-target-support-for-rtems-arm-xilinx-zedboard, r=tgross35
25891c8560a Rollup merge of rust-lang#101339 - the8472:ci-randomize-debug, r=Mark-Simulacrum
eb4746892bf fix: correct {Path,OsStr}::to_string_lossy() docs
76972316fb6 docs: add digit separators in `Duration` examples
9ed92df9886 replace placeholder version
00e12f791e4 Update marker.rs
5de059ff2d0 Update marker.rs
72e79f0c1de Update marker.rs
870dfeddde9 Update marker.rs
de72cd33be9 Elaborate on deriving vs implementing `Copy`
fee63007a49 More robust extension checking
ae90e450fd9 Port std library to RTEMS
c313c072ba2 Rollup merge of rust-lang#129916 - tshepang:basic-usage, r=ChrisDenton
c501959a497 Rollup merge of rust-lang#129913 - saethlin:l4re-read-buf, r=Noratrieb
83524b98e8b Rollup merge of rust-lang#129885 - cuishuang:master, r=scottmcm
e41afdc2cc8 Rollup merge of rust-lang#129800 - ChrisDenton:remove-dir-all2, r=Amanieu
851f5b63258 Add `Waker::new` and `LocalWaker::new`
a2b8bb8baae Stabilize waker_getters
2ec266b2cd4 Move the `data` and `vtable` methods from `RawWaker` to `Waker`
562fdcec802 process.rs: remove "Basic usage" text where not useful
9b3c3fecc0d Rollup merge of rust-lang#129907 - saethlin:solid-io-error, r=WaffleLapkin
02cecebd3a9 Rollup merge of rust-lang#129892 - oskgo:clarify-slice-from-raw, r=RalfJung
ccc294c2a53 Rollup merge of rust-lang#129890 - alex:patch-1, r=workingjubilee
6d0e687304b Rollup merge of rust-lang#129856 - RalfJung:compiler_fence, r=thomcc
0ccc851a07e Rollup merge of rust-lang#129748 - RalfJung:box-validity, r=workingjubilee
37618495ad7 Add missing read_buf stub for x86_64-unknown-l5re-uclibc
3b8ab5a6439 Fix compile error in solid's remove_dir_all
e14b9f387e8 clarify language around non-null ptrs in slice::raw
9a76abd8364 Remove stray word in a comment
1dd630f2324 Auto merge of rust-lang#129873 - matthiaskrgr:rollup-bv849ud, r=matthiaskrgr
26498824037 chore: remove repetitive words
7fd784ec2ba Rollup merge of rust-lang#129804 - ranger-ross:fixed-documentation-typos, r=Noratrieb
e4e9f6b9248 Rollup merge of rust-lang#129793 - lolbinarycat:doc-missing-newlines, r=workingjubilee
c4aa66aca88 Auto merge of rust-lang#129063 - the8472:cold-opt-size, r=Amanieu
4e3dbeedf82 add extra linebreaks so rustdoc can identify the first sentence
e00784f5e85 compiler_fence documentation: emphasize synchronization, not reordering
8d8dbe91b02 tweak wording regarding Box validity
065844bb5f0 Auto merge of rust-lang#127897 - nyurik:add-qnx-70-target, r=saethlin
759399be7a3 Rollup merge of rust-lang#129832 - eduardosm:stray-dot, r=jhpratt
60f37e4ad71 Rollup merge of rust-lang#129207 - GrigorenkoPV:elided-is-named, r=cjgillot
68e6537ba28 Rollup merge of rust-lang#128641 - Konippi:standardize-duplicate-processes-in-parser, r=scottmcm
b93e3abbf07 Rollup merge of rust-lang#128495 - joboet:more_memcmp, r=scottmcm
64c1db22d08 when -Zrandomize-layout is enabled disable alloc test testing internal struct sizes
d432698157c Auto merge of rust-lang#129831 - matthiaskrgr:rollup-befq6zx, r=matthiaskrgr
77cf0ba112b Remove stray dot in `std::char::from_u32_unchecked` documentation
ef033b028ed Rollup merge of rust-lang#129826 - Alcaro:patch-1, r=workingjubilee
2ad03e02998 Rollup merge of rust-lang#129650 - Zalathar:profiler-builtins, r=Mark-Simulacrum
c33b3dfa8ec Update mod.rs
24ed1c124d6 Rollup merge of rust-lang#129785 - RalfJung:miri-sync, r=RalfJung
50681ab44e8 Rollup merge of rust-lang#129730 - RalfJung:float-arithmetic, r=workingjubilee
0402bb10c5a Fix `elided_named_lifetimes` in code
667d060bfd6 Move remove_dir_all impl into a module
ae18edf95f4 Rollup merge of rust-lang#129754 - alexcrichton:fix-wasi-long-sleep, r=workingjubilee
9138bd188f5 Rollup merge of rust-lang#129675 - lolbinarycat:bufreader_peek_unsized, r=workingjubilee
83cadd0fe20 Rollup merge of rust-lang#129642 - workingjubilee:bump-backtrace-fc37b22, r=workingjubilee
d9af971403a Rollup merge of rust-lang#129640 - saethlin:unignore-android-in-alloc, r=tgross35
6b12a632e1d Fixed more typos in library/core
40f9251a0cd Fixed typos in btree map docs
628be3dae28 Fixed some typos in the standard library documentation/comments
21e893e6b6d enumerate the two parts of the NaN rules
081353cd333 add hyphen in floating-point
c664843f3b7 Squashed `aarch64_unknown_nto_qnx700` support
5c4c81a7c61 Merge from rustc
a37464739a6 Try latest backtrace
2c75dd81561 wasi: Fix sleeping for `Duration::MAX`
374229a0231 Rollup merge of rust-lang#128166 - ChaiTRex:isqrt, r=tgross35
f0dce767de0 Rollup merge of rust-lang#123940 - kornelski:remove-derived-debug, r=Urgau
228ec9e62ac Box validity: update for new zero-sized rules
93a72daf8ad f32 docs: define 'arithmetic' operations
1bc188fd531 Merge from rustc
c44af617f84 Speed up `checked_isqrt` and `isqrt` methods
21396512b94 Improve `isqrt` tests and add benchmarks
7c1560f9833 Rollup merge of rust-lang#129715 - Amjad50:update-compiler-builtins, r=tgross35
d2a001df590 Rollup merge of rust-lang#129683 - RalfJung:copysign, r=thomcc
8753a357ece Rollup merge of rust-lang#129673 - matthewpipie:arc-weak-debug-trait, r=dtolnay
3e1f63a7ab6 Rollup merge of rust-lang#129401 - workingjubilee:partial-initialization-of-stabilization, r=dtolnay,joboet
cd59153e222 Rollup merge of rust-lang#129378 - goffrie:patch-3, r=ChrisDenton
6d31b6de716 Rollup merge of rust-lang#128192 - mrkajetanp:feature-detect, r=Amanieu
60fd9c980c3 Update `compiler_builtins` to `0.1.123`
86c924ff3e5 fmt-debug option
8623fa49bac allow BufReader::peek to be called on unsized types
b1a56b508b6 Auto merge of rust-lang#129691 - matthiaskrgr:rollup-owlcr3m, r=matthiaskrgr
39ad6a926e3 Rollup merge of rust-lang#129668 - coolreader18:fix-pin-set-regr, r=dtolnay
5a4fe4044d8 Rollup merge of rust-lang#129657 - jswrenn:transmute-name, r=compiler-errors
1d44fabf570 Rollup merge of rust-lang#129551 - RalfJung:ub-checks-fallback, r=saethlin
b0fee9815c8 Rollup merge of rust-lang#129480 - lolbinarycat:euclid-docs, r=joboet
c8d3265d52d Enable some ilog2 tests as well
da08ef4ef5a Re-enable android tests/benches in alloc
bfbe13e1767 Auto merge of rust-lang#129589 - saethlin:improve-panic-immediate-abort, r=tgross35
89021c809f8 copysign with sign being a NaN is non-portable
ed66a11c68e addr_of on places derived from raw pointers should preserve permissions
17298981159 Add fmt::Debug to sync::Weak<T, A>
927a6da67ab Fix Pin::set bounds regression
9876bd1014d library: Stabilize new_uninit for Box, Rc, and Arc
a0ea69f6e4e Rollup merge of rust-lang#129652 - RalfJung:ptr-to-ref, r=traviscross
c7cbb41d48c Rollup merge of rust-lang#129645 - beetrees:fix-float-docs, r=tgross35
04eabb59f6a Rollup merge of rust-lang#129581 - RalfJung:exit, r=joshtriplett
33e2d7e8de6 safe transmute: Rename `BikeshedIntrinsicFrom` to `TransmuteFrom`
72c676f1fdb Auto merge of rust-lang#128134 - joboet:move_pal_alloc, r=cupiver
c108af0dbf3 fix Pointer to reference conversion docs
193310350fc clarify that addr_of creates read-only pointers
4f6b8149292 rustc_target: Add SME aarch64 features
012bb44c6c5 rustc_target: Add various aarch64 features
4dc5b675267 std: move allocators to `sys`
264fa88ed6a Don't skip nonexistent source files
5298b521b75 Add `cargo::rerun-if-changed` directives for source directories
5defa797459 Always include `WindowsMMap.c` in the list of source files
91d2ecf1eca Sort the list of source files
cb468d737ba Remove `InstrProfilingBiasVar.c` from the list of source files
0e0134f5d4b Use helper functions to read environment variables
a628540ba41 Rollup merge of rust-lang#129559 - RalfJung:float-nan-semantics, r=thomcc
00c8f98e15e Rollup merge of rust-lang#128731 - RalfJung:simd-shuffle-vector, r=workingjubilee
6d3344f0919 Update old comment referring to `libcompiler_builtins`
6d8a1f6903e Reflow a couple of paragraphs in floating-point primitive docs
8834d35fa4b Fix typos in floating-point primitive type docs
54c986a8287 Bump backtrace to rust-lang/backtrace@fc37b22
932cbd42f14 Rollup merge of rust-lang#129032 - jswrenn:transmute-method, r=compiler-errors
28a983de9a8 Rollup merge of rust-lang#128157 - lolbinarycat:unify-ptr-ref-docs, r=cuviper
d1e21bdba8d Apply suggestions from code review
febaf22f00e Rollup merge of rust-lang#129592 - saethlin:core-cfg-test, r=tgross35
77a1318f7f7 Rollup merge of rust-lang#129588 - hermit-os:sleep-micros, r=workingjubilee
12fe23bd5dc Rollup merge of rust-lang#129539 - oconnor663:poll_link, r=tgross35
864e465be7b Rollup merge of rust-lang#129377 - chorman0773:unbounded-shifts-impl, r=scottmcm
07cfc6ae040 also update copysign docs
acaef605e72 move per-target NaN info into a table
854ba7e4cef float types: document NaN bit pattern guarantees
d958260763a Auto merge of rust-lang#129595 - matthiaskrgr:rollup-4udn7nn, r=matthiaskrgr
8dd3363de6a Remove cfg(test) from library/core
cd554e2b4ea Rollup merge of rust-lang#129544 - mu001999-contrib:dead-code/clean, r=compiler-errors
ff769eef88a Rollup merge of rust-lang#129525 - notriddle:notriddle/fake-variadic-tuple-array, r=GuillaumeGomez
4d22c1c6b37 Auto merge of rust-lang#129488 - saethlin:alignment-precondition, r=workingjubilee
c688deff96a pal/hermit: saturate `usleep` microseconds at `u64::MAX`
8ea71ae5647 Auto merge of rust-lang#129563 - matthiaskrgr:rollup-t6bai2d, r=matthiaskrgr
46eff207f56 Tweak some attributes to improve panic_immediate_abort
fdb5fc1fca6 pal/hermit: correctly round up microseconds in `Thread::sleep`
b392703506b exit: explain our expectations for the exit handlers registered in a Rust program
22ec8977a9a link to Future::poll from the Poll docs
a994fbbca83 Rollup merge of rust-lang#129487 - GrigorenkoPV:repr_transparent_external_private_fields, r=compiler-errors
3a339226a95 Rollup merge of rust-lang#129416 - workingjubilee:partial-move-from-stabilization, r=dtolnay
3a8de952989 Rollup merge of rust-lang#129091 - RalfJung:box_as_ptr, r=Amanieu
4de4debd1eb Auto merge of rust-lang#129295 - Zalathar:profiler-builtins, r=Kobzol
0872cf30408 ub_checks intrinsics: fall back to cfg(ub_checks)
8dafd337e12 Auto merge of rust-lang#129521 - matthiaskrgr:rollup-uigv77m, r=matthiaskrgr
d9e489b48ce Removes dead code from the compiler
c14cf57e404 Rollup merge of rust-lang#129481 - scottmcm:update-cb, r=tgross35
acf6f03b6fa Rollup merge of rust-lang#129449 - coolreader18:pin-as_deref_mut-signature, r=dtolnay
112ebc4d5a9 Rollup merge of rust-lang#128735 - jieyouxu:pr-120176-revive, r=cjgillot
49aa496c5bb rustdoc: clean up tuple <-> primitive conversion docs
0fe374666ac Rollup merge of rust-lang#129501 - RalfJung:miri-rust-backtrace, r=Noratrieb
7d5cf38931b Rollup merge of rust-lang#129500 - fee1-dead-contrib:fxrel, r=compiler-errors
e91d825f826 Rollup merge of rust-lang#129323 - Urgau:ptr_fn_addr_eq, r=Mark-Simulacrum
f6470795864 Rollup merge of rust-lang#128596 - RalfJung:const_fn_floating_point_arithmetic, r=nnethercote
f965950f05e New `#[rustc_pub_transparent]` attribute
a6ea125cb0e panicking: improve hint for Miri's RUST_BACKTRACE behavior
a437005e6f3 Build `library/profiler_builtins` from `ci-llvm` if appropriate
693477a3f65 remove invalid `TyCompat` relation for effects
82fc74f6f1a library: Move unstable API of new_uninit to new features
3ee2e18c8dc Enable Alignment::new_unchecked precondition check
0803686e7fb Change `f16` doctests in core to run on x86-64 linux
9359a126d41 Update `compiler_builtins` to `0.1.121`
da02e8b5609 Enable `f16` tests on x86 and x86-64
f3a198e85be docs: correct panic conditions for rem_euclid and similar functions
976fb4aeefc Move into_inner_unchecked back to the bottom of the impl block
2741e8dacb4 Put Pin::as_deref_mut in impl Pin<Ptr>
88790f80130 document & impl the transmutation modeled by `BikeshedIntrinsicFrom`
f670207d0f4 Auto merge of rust-lang#129464 - GuillaumeGomez:rollup-ckfqd7h, r=GuillaumeGomez
5bf661cc64f Rollup merge of rust-lang#129276 - eduardosm:stabilize-char_indices_offset, r=Amanieu
e2614f24b27 Rollup merge of rust-lang#129400 - Amjad50:update-compiler-builtins, r=tgross35
2c06146be10 Rollup merge of rust-lang#127623 - lolbinarycat:fix_remove_dir_all, r=Amanieu
eb747e53dd0 Check that `library/profiler_builtins` actually found some source files
eae79872269 fix typos in new pointer conversion docs
fe33d2c256c fix: fs::remove_dir_all: treat ENOENT as success
3fd591ebdef feat(core): Make `unbounded_shl{l,r}` unstably const and remove `rustc_allow_const_fn_unstable`
2168ce32967 Auto merge of rust-lang#129398 - matthiaskrgr:rollup-50l01ry, r=matthiaskrgr
12944c76047 Update `compiler_builtins` to `0.1.120`
7496478b7a5 stabilize const_fn_floating_point_arithmetic
6f534f94217 Rollup merge of rust-lang#129382 - tgross35:once-cell-const-into-inner, r=Noratrieb
2535017098e Rollup merge of rust-lang#129376 - ChaiTRex:assert_unsafe_precondition_check_language_ub, r=workingjubilee,the8472
4ec19afe669 Rollup merge of rust-lang#129374 - ChaiTRex:digit_unchecked_assert_unsafe_precondition, r=scottmcm
024ec3c0f62 Rollup merge of rust-lang#128432 - g0djan:godjan/wasi_prohibit_implicit_unsafe, r=tgross35
f671c1129b9 Auto merge of rust-lang#129365 - matthiaskrgr:rollup-ebwx6ya, r=matthiaskrgr
5299ef149b1 fix(core): Use correct operations/values in `unbounded_shr` doctests
84230062104 chore: `x fmt`
cbe7338e1f3 fix(core): Add `#![feature(unbounded_shifts)]` to doctests for `unbounded_shr`/`unbounded_shl`
863123bd7c4 Add `const_cell_into_inner` to `OnceCell`
b51f35e9d47 format
6fd539327d2 chore: `x fmt` and hopefully fix the tidy issue
e99c681c95b Clean up cfg-gating of ProcessPrng extern
9d2bb976994 Change `assert_unsafe_precondition` docs to refer to `check_language_ub`
32bd5dfb369 chore: Also format the control flow
5f8cf71d7d6 Manually format functions and use `rhs` instead of `v` from my CE testing
700af565751 feat(core): Add implementations for `unbounded_shl`/`unbounded_shr`
a9ad57eb6a1 Use `assert_unsafe_precondition!` in `AsciiChar::digit_unchecked`
77bd65fdedc Rollup merge of rust-lang#129321 - krtab:float_sum, r=workingjubilee
cc219788b51 Rollup merge of rust-lang#129232 - ivmarkov:master, r=workingjubilee
c9cf844ccd3 Rollup merge of rust-lang#127945 - tgross35:debug-more-non-exhaustive, r=Noratrieb
d37ebfea900 Rollup merge of rust-lang#129332 - cuviper:cstr-cast, r=compiler-errors
6d01ed8b3bd Rollup merge of rust-lang#129312 - tbu-:pr_str_not_impl_error, r=Noratrieb
93319c80754 Fix stability attribute of `impl !Error for &str`
7f8bdd574b6 Auto merge of rust-lang#126556 - saethlin:layout-precondition, r=joboet
9e9141f54eb Auto merge of rust-lang#128866 - scottmcm:update-stdarch, r=tgross35
d47cfba89b7 Update stdarch submodule
b507a8bfeb9 Try to golf down the amount of code in Layout
32b574e848f Avoid extra `cast()`s after `CStr::as_ptr()`
9d4113ff24d Rollup merge of rust-lang#129294 - scottmcm:stabilize-repeat-n, r=Noratrieb
62d240d9b6a Implement `ptr::fn_addr_eq`
529e33acb80 Change neutral element of <fNN as iter::Sum> to neg_zero
126935f7257 Stabilize `iter::repeat_n`
91439ce7b58 Auto merge of rust-lang#129226 - RalfJung:libc, r=Mark-Simulacrum
bef7be0e71e Add a precondition check for Layout::from_size_align_unchecked
a55ab85ad47 Stabilize feature `char_indices_offset`
7f45dcfa195 library: bump libc dependency
ebe99f3b8b6 Rollup merge of rust-lang#128902 - evanj:evan.jones/env-var-doc, r=workingjubilee
8bdd95ba4da soft-deprecate the addr_of macros
23b0aadc2ce code review improvements
0b0dad4af6f Fix for issue rust-lang#129212 for the ESP-IDF
bd7aa576572 Auto merge of rust-lang#126877 - GrigorenkoPV:clone_to_uninit, r=dtolnay
d3c08f8f8ac Auto merge of rust-lang#128598 - RalfJung:float-comments, r=workingjubilee
dc5fed53253 Auto merge of rust-lang#106943 - mina86:exact_size_take_repeat, r=dtolnay
88927ac26eb Auto merge of rust-lang#116528 - daxpedda:stabilize-ready-into-inner, r=dtolnay
9952947d86b Rollup merge of rust-lang#129161 - dtolnay:spawnunck, r=Noratrieb
db3abec9727 Rollup merge of rust-lang#129086 - slanterns:is_none_or, r=dtolnay
44a558dc7dc Stabilize std::thread::Builder::spawn_unchecked
5c553c41134 float to/from bits and classify: update comments regarding non-conformant hardware
9704e2df60c Rollup merge of rust-lang#128064 - ijackson:noop-waker-doc, r=workingjubilee
0497f0c6c91 Add cautionary paragraph about noop wakers.
16dd42669a2 Rollup merge of rust-lang#128946 - orlp:faster-ip-hash, r=joboet
383c4db14b0 Rollup merge of rust-lang#128925 - dingxiangfei2009:smart-ptr-helper-attr, r=compiler-errors
ba3a942d5de Rollup merge of rust-lang#125970 - RalfJung:before_exec, r=m-ou-se
32a71bb1dc7 size-optimize some of the panic dependencies
d7b85f24937 apply #[optimize(size)] to #[cold] ones and part of the panick machinery
0dbf8cff9de Rollup merge of rust-lang#128954 - zachs18:fromresidual-no-default, r=scottmcm
4f0959927f2 Rollup merge of rust-lang#128570 - folkertdev:stabilize-asm-const, r=Amanieu
b6c9e44d2a6 add Box::as_ptr and Box::as_mut_ptr methods
23d1309b02e CommandExt::before_exec: deprecate safety in edition 2024
9858d49b168 stabilize `is_none_or`
fd2b339c5a6 Auto merge of rust-lang#129060 - matthiaskrgr:rollup-s72gpif, r=matthiaskrgr
3b8aab7df81 Rollup merge of rust-lang#129001 - cblh:fix/128713, r=Noratrieb
16edf695130 Rollup merge of rust-lang#128873 - ChrisDenton:windows-targets, r=Mark-Simulacrum
0199b00c91f Rollup merge of rust-lang#128759 - notriddle:notriddle/spec-to-string, r=workingjubilee,compiler-errors
c6dc243b917 stabilize `asm_const`
b4bfc215048 Rollup merge of rust-lang#129034 - henryksloan:coroutine-must-use, r=joboet
b56fdcb2730 Rollup merge of rust-lang#127857 - tbu-:pr_deprecated_safe_todo, r=petrochenkov
77f462da866 Rollup merge of rust-lang#122884 - mzabaluev:pow-remove-exit-branch, r=Amanieu
0a6a74bce1a Reduce merged doctest source code size
a83dde61642 Mark location doctest as standalone since file information will not work in merged doctest file
7334c7178ce Auto merge of rust-lang#129046 - matthiaskrgr:rollup-9x4xgak, r=matthiaskrgr
9ed72103664 Rollup merge of rust-lang#128745 - dtolnay:spawnunchecked, r=workingjubilee
c39d90e4d51 Rollup merge of rust-lang#128655 - joboet:play_with_the_dice, r=ChrisDenton
f81c96a863e `#[deprecated_safe_2024]`: Also use the `// TODO:` hint in the compiler error
23a19685c9b Allow to customize `// TODO:` comment for deprecated safe autofix
37017c0f6f6 Auto merge of rust-lang#128962 - devnexen:fs_get_mode_haiku, r=workingjubilee
6ad03a7161f simd_shuffle intrinsic: allow argument to be passed as vector (not just as array)
8a2671a2889 Revert to original loop for const pow exponents
c5e81895dfb Auto merge of rust-lang#128742 - RalfJung:miri-vtable-uniqueness, r=saethlin
ac682f19873 Add must_use attribute to Coroutine trait
658904d1a9a chore(lib): fmt core::fmt::Formatter's write_fmt method
7eb73762bb3 trying common codepath for every unixes
5fabf93c765 std::fs: get_mode implementation for haiku.
e3da824e62c Rollup merge of rust-lang#129017 - its-the-shrimp:core_fmt_from_fn, r=Noratrieb
b247d9a7a9a derive(SmartPointer): register helper attributes
aa854485cea Explicitly specify type parameter on FromResidual impls in stdlib.
262a4f6b641 std::fmt::FormatterFn -> std::fmt::FromFn
ceceae30ced Rollup merge of rust-lang#128632 - joboet:dont_overwrite_style, r=Amanieu
e8f7afeb117 Rollup merge of rust-lang#128149 - RalfJung:nontemporal_store, r=jieyouxu,Amanieu,Jubilee
7dd208356e1 chore(lib): Enhance documentation for core::fmt::Formatter's write_fmt method
048efd0bcec ignore some vtable/fn ptr equality tests in Miri, their result is not fully predictable
a367a12df0a std: use `/scheme/rand` on Redox
4b816b496d5 core: make documentation clearer, rename slice comparison specialization trait
1ca6b42583f std: do not overwrite style in `get_backtrace_style`
91477777de1 Auto merge of rust-lang#128862 - cblh:fix/128855, r=scottmcm
56e1afe0810 Auto merge of rust-lang#126793 - saethlin:mono-rawvec, r=scottmcm
ec7a585087c Do not use unnecessary endian conversion.
f48facfed72 Rollup merge of rust-lang#128882 - RalfJung:local-waker-will-wake, r=cuviper
b581949746c Rollup merge of rust-lang#120314 - mina86:i, r=Mark-Simulacrum
451feca66ac Fix stability annotation and expand comment
2e34ac388e0 Hash Ipv*Addr as an integer
b8b61e1e931 Auto merge of rust-lang#128927 - GuillaumeGomez:rollup-ei2lr0f, r=GuillaumeGomez
44f5b4fe515 Rollup merge of rust-lang#128273 - Voultapher:improve-ord-violation-help, r=workingjubilee
3d7afa0e721 Update std and compiler
971df1c2948 Stabilize `min_exhaustive_patterns`
c37c6665b9b Add an optimizer hint for the capacity that with_capacity_in returns
c8cbd5c499c Hoist IS_ZST check out of RawVecInner::from_*_in
e843f7103a0 Polymorphize RawVec
dc39cbf9234 core: optimise Debug impl for ascii::Char
9668691af5d doc: std::env::var: Returns None for names with '=' or NUL byte
5d5d8bc73a9 Rollup merge of rust-lang#128859 - MinxuanZ:mips-sig, r=Amanieu
825def017bc Rollup merge of rust-lang#128817 - biabbas:vxworks_update, r=tgross35
6e933a82c90 make LocalWaker::will_wake consistent with Waker::will_wake
118c71296c8 Fix linkchecker issue
b1460b93704 Exclude windows-targets from the workspace
a3a6a9856c2 Add windows-targets crate to std's sysroot
f74940d94c2 Rollup merge of rust-lang#128824 - GuillaumeGomez:update-compiler-builtins, r=Amanieu
39b1eafc08c VxWorks: Add safety comment for vxCpuEnabledGet
8b0a25df983 fix: Ensure `Guard`'s `drop` method is removed at `opt-level=s` for `Copy` types
c54958c5dad delete space
dadbd585cb3 fix format
7c34ebf93de [SPARC] fix the name of signal 19 in sparc arch
b75648a7515 [MIPS] fix the name of signal 19 in mips
3840b09aae3 Rollup merge of rust-lang#128818 - RalfJung:std-miri-floats, r=tgross35
d03bb5e33a9 Rollup merge of rust-lang#128640 - RalfJung:rwlock-macos-miri, r=joboet
7680a3c7598 Rollup merge of rust-lang#128749 - tgross35:float-inline, r=scottmcm
9df61adfaa1 Rollup merge of rust-lang#128306 - WiktorPrzetacznik:WiktorPrzetacznik-nonnull-alignoffset-update, r=Amanieu
39860ad52d1 Update compiler-builtins version to 0.1.118
42811859e46 std float tests: special-case Miri in feature detection
4d6b36adfe6 Vxworks: Extern taskNameSet and fix build errors
e24a6ca11fa rwlock: disable 'frob' test in Miri on macOS
c21ba971a8a Fix VxWorks available parallelism: Move nonzero::uncheked into unsafe block
249541802ec Rollup merge of rust-lang#128800 - clarfonthey:core-pattern-type, r=compiler-errors
79cd72af482 Rollup merge of rust-lang#128691 - tgross35:update-builtins, r=Amanieu
8f840157d66 Add tracking issue to core-pattern-type
b8f7f384f75 Stabilize `Ready::into_inner()`
62ccdeb315d Rollup merge of rust-lang#128261 - clarfonthey:iter-default, r=dtolnay
b4e53303f07 alloc: make `to_string_str!` a bit less complex
ec74467d64c Mark `{f32,f64}::{next_up,next_down,midpoint}` inline
b90a026d6f8 Rollup merge of rust-lang#128766 - Monadic-Cat:patch-1, r=tgross35
5d7906c0270 Rollup merge of rust-lang#128417 - tgross35:f16-f128-math, r=dtolnay
83d1d167737 Trivial grammar fix in const keyword docs
97384fa701b Update `compiler-builtins` to 0.1.117
6dc79bb6235 Rollup merge of rust-lang#128751 - devnexen:vxworks_set_thread_name, r=tgross35
432425d28f7 Rollup merge of rust-lang#128539 - biabbas:deny_unsafe, r=workingjubilee
1bd5338eadf Rollup merge of rust-lang#128406 - lolbinarycat:bufreader_peek, r=Mark-Simulacrum
e20aa6430f1 Rollup merge of rust-lang#125048 - dingxiangfei2009:stable-deref, r=amanieu
bc13c6ca57a alloc: add ToString specialization for `&&str`
14fe723f6b9 std::thread: set_name implementation proposal for vxWorks.
67fa603356d Remove unused lifetime parameter from spawn_unchecked
4a3da122172 Add a special case for CStr/CString in the improper_ctypes lint
51ec2bb7ea2 implement BufReader::peek
e6aede2233f nontemporal_store: make sure that the intrinsic is truly just a hint
a300df74d13 WASI fixing unsafe_op_in_unsafe_fn for std::{os, sys}
86336fcc0b1 std: refactor UNIX random data generation
8fe1e328a17 refactor: standardize duplicate processes in parser
6fafc6b5d92 Apply review comments to PartialOrd section
7850a64f5bb Forbid unsafe_op_in_unsafe_fn in vxworks specific os and sys files
e844efffe8f Add a disclaimer about x86 `f128` math functions
21d297b29ad Update comments for `{f16, f32, f64, f128}::midpoint`
ad27d08e73e Add `core` functions for `f16` and `f128` that require math routines
c6407b0bfa7 Add math functions for `f16` and `f128`
d9b1de5180d Add math intrinsics for `f16` and `f128`
3c1586b3ce8 Hide internal sort module
b927541dc3f core: use `compare_bytes` for more slice element types
21887129721 Apply review comments
2ebe00aa0ba PinCoerceUnsized trait into core
569ab6a3a03 CloneToUninit: use a private specialization trait
26874cc98cc Sparkle some attributes over `CloneToUninit` stuff
e8c37187b60 impl CloneToUninit for Path and OsStr
ef8c591ec02 impl CloneToUninit for str and CStr
65c6173bfe1 Update NonNull::align_offset quarantees
b014b0d7b74 Improve panic sections for sort*, sort_unstable* and select_nth_unstable*
9bcfe84e72b Improve panic message and surrounding documentation for Ord violations
7e55abb1837 Okay, I guess I have to give these a different feature name
bdc18e2ea2b impl Default for collection iterators that don't already have it
f26f981c731 clarify interactions with MaybeUninit and UnsafeCell
394c8640df0 remove duplicate explanations of the ptr to ref conversion rules
571348bc357 create a new section on pointer to reference conversion
971aa37f27b LocalWaker docs: Make long-ago omitted but probably intended changes
c4fdac9fe60 Docs for Waker and LocalWaker: Add cross-refs in comment
9c299bc6b10 Implement `debug_more_non_exhaustive`
b405024dc09 Make use of raw strings in `core::fmt::builders`
20e64bd6cd3 Use is_val_statically_known to optimize pow
05ee32298cb Explicitly unroll integer pow for small exponents
4cfe24a3555 Optimize integer pow by removing exit branch
7c219da2111 Implement DoubleEnded and ExactSize for Take<Repeat> and Take<RepeatWith>

git-subtree-dir: library
git-subtree-split: 4f47132d7d3b4bda9ac62743c058732b9d266236
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
O-Arm Target: 32-bit Arm processors (armv6, armv7, thumb...), including 64-bit Arm in AArch32 state O-unix Operating system: Unix-like S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.