dependabot/cargo/cpal-0.16
361 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
dependabot[bot]
|
265fefb865
|
Bump cargo-bins/cargo-binstall from 1.12.5 to 1.14.1 (#19877)
Bumps [cargo-bins/cargo-binstall](https://github.com/cargo-bins/cargo-binstall) from 1.12.5 to 1.14.1. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/cargo-bins/cargo-binstall/releases">cargo-bins/cargo-binstall's releases</a>.</em></p> <blockquote> <h2>v1.14.1</h2> <p><em>Binstall is a tool to fetch and install Rust-based executables as binaries. It aims to be a drop-in replacement for <code>cargo install</code> in most cases. Install it today with <code>cargo install cargo-binstall</code>, from the binaries below, or if you already have it, upgrade with <code>cargo binstall cargo-binstall</code>.</em></p> <h4>In this release:</h4> <ul> <li>Upgrade dependencies</li> </ul> <h2>v1.14.0</h2> <p><em>Binstall is a tool to fetch and install Rust-based executables as binaries. It aims to be a drop-in replacement for <code>cargo install</code> in most cases. Install it today with <code>cargo install cargo-binstall</code>, from the binaries below, or if you already have it, upgrade with <code>cargo binstall cargo-binstall</code>.</em></p> <h4>In this release:</h4> <ul> <li>Fix glibc detection on arm Fedora (<a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/2205">#2205</a>)</li> <li>Add support for repository host Codeberg (<a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/2202">#2202</a>)</li> <li>Fix error for missing binaries when <code>--bin</code> does not include any of these missing bins (<a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/1888">#1888</a> <a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/2199">#2199</a>)</li> </ul> <h4>Other changes:</h4> <ul> <li>Rm uninstalled crates from <code>$CARGO_HOME/binstall/crates-v1.json</code> (<a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/2197">#2197</a>)</li> <li>Upgrade dependencies</li> </ul> <h2>v1.13.0</h2> <p><em>Binstall is a tool to fetch and install Rust-based executables as binaries. It aims to be a drop-in replacement for <code>cargo install</code> in most cases. Install it today with <code>cargo install cargo-binstall</code>, from the binaries below, or if you already have it, upgrade with <code>cargo binstall cargo-binstall</code>.</em></p> <h4>In this release:</h4> <ul> <li>Add a <code>--bin</code> argument to mirror cargo install <code>--bin</code> (<a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/1961">#1961</a> <a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/2189">#2189</a>)</li> </ul> <h4>Other changes:</h4> <ul> <li>Upgrade dependencies</li> </ul> <h2>v1.12.7</h2> <p><em>Binstall is a tool to fetch and install Rust-based executables as binaries. It aims to be a drop-in replacement for <code>cargo install</code> in most cases. Install it today with <code>cargo install cargo-binstall</code>, from the binaries below, or if you already have it, upgrade with <code>cargo binstall cargo-binstall</code>.</em></p> <h4>In this release:</h4> <ul> <li>Fix updating installed crates manifest for custom registry (<a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/2175">#2175</a> <a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/2178">#2178</a>)</li> </ul> <h4>Other changes:</h4> <ul> <li>Upgrade transitive dependencies</li> <li>Ensure build script always waits for threads created (<a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/2185">#2185</a>)</li> <li>optimization</li> </ul> <h2>v1.12.6</h2> <p><em>Binstall is a tool to fetch and install Rust-based executables as binaries. It aims to be a drop-in replacement for <code>cargo install</code> in most cases. Install it today with <code>cargo install cargo-binstall</code>, from the binaries below, or if you already have it, upgrade with <code>cargo binstall cargo-binstall</code>.</em></p> <h4>In this release:</h4> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
dependabot[bot]
|
5d736a525c
|
Bump super-linter/super-linter from 7.3.0 to 7.4.0 (#19288)
Bumps [super-linter/super-linter](https://github.com/super-linter/super-linter) from 7.3.0 to 7.4.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/super-linter/super-linter/releases">super-linter/super-linter's releases</a>.</em></p> <blockquote> <h2>v7.4.0</h2> <h2><a href="https://github.com/super-linter/super-linter/compare/v7.3.0...v7.4.0">7.4.0</a> (2025-05-13)</h2> <h3>🚀 Features</h3> <ul> <li>add env var for npm-groovy-lint failon level (<a href="https://redirect.github.com/super-linter/super-linter/issues/6530">#6530</a>) (<a href=" |
||
|
dependabot[bot]
|
86f00e8127
|
Bump cargo-bins/cargo-binstall from 1.12.3 to 1.12.5 (#19289)
Bumps [cargo-bins/cargo-binstall](https://github.com/cargo-bins/cargo-binstall) from 1.12.3 to 1.12.5. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/cargo-bins/cargo-binstall/releases">cargo-bins/cargo-binstall's releases</a>.</em></p> <blockquote> <h2>v1.12.5</h2> <p><em>Binstall is a tool to fetch and install Rust-based executables as binaries. It aims to be a drop-in replacement for <code>cargo install</code> in most cases. Install it today with <code>cargo install cargo-binstall</code>, from the binaries below, or if you already have it, upgrade with <code>cargo binstall cargo-binstall</code>.</em></p> <h4>In this release:</h4> <ul> <li>Upgrade dependencies</li> </ul> <h2>v1.12.4</h2> <p><em>Binstall is a tool to fetch and install Rust-based executables as binaries. It aims to be a drop-in replacement for <code>cargo install</code> in most cases. Install it today with <code>cargo install cargo-binstall</code>, from the binaries below, or if you already have it, upgrade with <code>cargo binstall cargo-binstall</code>.</em></p> <h4>In this release:</h4> <ul> <li>Fix glibc detection on ubuntu 24.02 (<a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/2141">#2141</a> <a href="https://redirect.github.com/cargo-bins/cargo-binstall/issues/2143">#2143</a>)</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
github-actions[bot]
|
a466084167
|
Bump Version after Release (#19774)
Bump version after release This PR has been auto-generated Fixes #19766 --------- Co-authored-by: Bevy Auto Releaser <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: François Mockers <francois.mockers@vleue.com> Co-authored-by: François Mockers <mockersf@gmail.com> |
||
|
François Mockers
|
4e694aea53
|
ECS: put strings only used for debug behind a feature (#19558)
# Objective - Many strings in bevy_ecs are created but only used for debug: system name, component name, ... - Those strings make a significant part of the final binary and are no use in a released game ## Solution - Use [`strings`](https://linux.die.net/man/1/strings) to find ... strings in a binary - Try to find where they come from - Many are made from `type_name::<T>()` and only used in error / debug messages - Add a new structure `DebugName` that holds no value if `debug` feature is disabled - Replace `core::any::type_name::<T>()` by `DebugName::type_name::<T>()` ## Testing Measurements were taken without the new feature being enabled by default, to help with commands ### File Size I tried building the `breakout` example with `cargo run --release --example breakout` |`debug` enabled|`debug` disabled| |-|-| |81621776 B|77735728B| |77.84MB|74.13MB| ### Compilation time `hyperfine --min-runs 15 --prepare "cargo clean && sleep 5" 'RUSTC_WRAPPER="" cargo build --release --example breakout' 'RUSTC_WRAPPER="" cargo build --release --example breakout --features debug'` ``` breakout' 'RUSTC_WRAPPER="" cargo build --release --example breakout --features debug' Benchmark 1: RUSTC_WRAPPER="" cargo build --release --example breakout Time (mean ± σ): 84.856 s ± 3.565 s [User: 1093.817 s, System: 32.547 s] Range (min … max): 78.038 s … 89.214 s 15 runs Benchmark 2: RUSTC_WRAPPER="" cargo build --release --example breakout --features debug Time (mean ± σ): 92.303 s ± 2.466 s [User: 1193.443 s, System: 33.803 s] Range (min … max): 90.619 s … 99.684 s 15 runs Summary RUSTC_WRAPPER="" cargo build --release --example breakout ran 1.09 ± 0.05 times faster than RUSTC_WRAPPER="" cargo build --release --example breakout --features debug ``` |
||
|
François Mockers
|
2961f44dcd
|
don't deny warnings on wasm-atomics CI job (#19604)
# Objective - CI job checking for wasm atomics fails because of an unrelated lint on nightly rust - Fixes #19573 ## Solution - Don't deny warning, that's not what this job is checking anyway |
||
|
dependabot[bot]
|
06bb57c326
|
Bump crate-ci/typos from 1.32.0 to 1.33.1 (#19551)
Bumps [crate-ci/typos](https://github.com/crate-ci/typos) from 1.32.0 to 1.33.1. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/crate-ci/typos/releases">crate-ci/typos's releases</a>.</em></p> <blockquote> <h2>v1.33.1</h2> <h2>[1.33.1] - 2025-06-02</h2> <h3>Fixes</h3> <ul> <li><em>(dict)</em> Don't correct <code>wasn't</code> to <code>wasm't</code></li> </ul> <h2>v1.33.0</h2> <h2>[1.33.0] - 2025-06-02</h2> <h3>Features</h3> <ul> <li>Updated the dictionary with the <a href="https://redirect.github.com/crate-ci/typos/issues/1290">May 2025</a> changes</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/crate-ci/typos/blob/master/CHANGELOG.md">crate-ci/typos's changelog</a>.</em></p> <blockquote> <h2>[1.33.1] - 2025-06-02</h2> <h3>Fixes</h3> <ul> <li><em>(dict)</em> Don't correct <code>wasn't</code> to <code>wasm't</code></li> </ul> <h2>[1.33.0] - 2025-06-02</h2> <h3>Features</h3> <ul> <li>Updated the dictionary with the <a href="https://redirect.github.com/crate-ci/typos/issues/1290">May 2025</a> changes</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Carter Anderson
|
7e9d6d852b
|
bevyengine.org -> bevy.org (#19503)
We have acquired [bevy.org](https://bevy.org) and the migration has finished! Meaning we can now update all of the references in this repo. |
||
|
Carter Anderson
|
fdf5dd677f
|
Update FUNDING.yml | ||
|
Niklas Eicker
|
7c4a1f9d87
|
Unpin nightly in CI (#19278)
# Objective In #19253 we pinned nightly due to a bug in Miri. That issue was resolved and the latest Miri should be usable for us again. ## Solution - Use latest nightly again ## Testing - I tested today's Miri locally with `RUSTUP_TOOLCHAIN=nightly-2025-05-18 MIRIFLAGS="-Zmiri-ignore-leaks -Zmiri-disable-isolation" RUSTFLAGS="-Zrandomize-layout" cargo miri test -p bevy_ecs` |
||
|
Niklas Eicker
|
6397a28bbf
|
Pin nightly due to miri issue (#19253)
# Objective The required miri check is currently failing due to rust-lang/miri#4323 Let's pin nightly to yesterday to not be blocked today. ## Solution - Pinned nightly to `nightly-2025-05-16` ## Testing - Let's see if the pipeline is green on this PR :D |
||
|
MichiRecRoom
|
b19f644c2f
|
The toml workflow job will now install taplo-cli using cargo-binstall (#18773)
# Objective Avoid needing to compile `taplo-cli` every time we use it in CI. ## Solution Use [cargo-binstall](https://github.com/cargo-bins/cargo-binstall) to install `taplo-cli`. cargo-binstall is different from `cargo install`, in that it will first attempt download a precompiled `taplo-cli` binary, in an attempt to avoid compilation. However, failing that (for any reason), it will fall back to installing the binary through `cargo install`. While installing `taplo-cli` from source is relatively fast (around 50-60s), this still provides a small speed boost to the job, by not needing to spend time compiling `taplo-cli` from source at all. ## Note on how this affects workflows This PR does have one side-effect: Should `taplo-cli` need to be compiled from source at all, it is no longer guaranteed to use the latest `stable` version of `rustc`. This may be considered problematic, as `taplo-cli` doesn't appear to have a MSRV policy. However, its MSRV (as of writing this PR) is `1.74` - a nearly 1.5 year old version. This seems to imply that, if `taplo-cli`'s MSRV is ever updated, it won't be to the absolute latest stable version of Rust until said version is a few months old. Combine that with [the Github Actions runner images being frequently (and automatically) updated to use the latest Rust tooling](https://github.com/actions/runner-images/pull/11957), and I don't foresee `taplo-cli`'s MSRV being an issue in 99% of circumstances. Still, there is the possibility of it being a problem in those 1% of circumstances - if this is a concern, please let me know and I'll try to fix it. ## Testing This change was tested on my local fork. The specific job run can be found [here](https://github.com/LikeLakers2/bevy/actions/runs/14350945588/job/40229485624). --------- Co-authored-by: François Mockers <francois.mockers@vleue.com> |
||
|
Greeble
|
b516e78317
|
Bump crate-ci/typos from 1.31.1 to 1.32.0 (#19072)
Adopted #19066. Bumps [crate-ci/typos](https://github.com/crate-ci/typos) from 1.31.1 to 1.32.0. --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
dependabot[bot]
|
ce5a82b2bf
|
Bump crate-ci/typos from 1.31.0 to 1.31.1 (#18744)
Bumps [crate-ci/typos](https://github.com/crate-ci/typos) from 1.31.0 to 1.31.1. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/crate-ci/typos/releases">crate-ci/typos's releases</a>.</em></p> <blockquote> <h2>v1.31.1</h2> <h2>[1.31.1] - 2025-03-31</h2> <h3>Fixes</h3> <ul> <li><em>(dict)</em> Also correct <code>typ</code> to <code>type</code></li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/crate-ci/typos/blob/master/CHANGELOG.md">crate-ci/typos's changelog</a>.</em></p> <blockquote> <h2>[1.31.1] - 2025-03-31</h2> <h3>Fixes</h3> <ul> <li><em>(dict)</em> Also correct <code>typ</code> to <code>type</code></li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Martín Maita
|
5973ba418f
|
Bump crate-ci/typos from 1.30.2 to 1.31.0 (#18656)
# Objective - Fixes #18642 ## Solution - Bumped crate-ci/typos from 1.30.2 to 1.31.0. - Fixed typos. ## Testing - Typos were fixed. --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
Alice Cecile
|
00a84d657a
|
Delete migration guide section from PR template (#18575)
# Objective Due to the work outlined in #18441, we're no longer storing the migration guides on the PR description. ## Solution Delete the section of the PR template that suggests you do this. |
||
|
Miles Silberling-Cook
|
0a2e183476
|
Add basic release content tagging workflow (#18568)
# Objective This PR begins integrating the new releate-content drafting process (https://github.com/bevyengine/bevy/pull/18427) into our GitHub workflows. It's similar to what we had before: Messages are posted to PRs tagged with `M-Needs-Release-Note` or `M-Needs-Migration-Guide` asking them to add the required material and linking to the instructions. These messages do not trigger if the PR already has modified files in the `release-notes` or `migration-guides` directories (respectively). I have also re-arranged and content slightly (to remove the need for a directory with the current version number), tweaked the language, and switched the templates to use the [standard markdown frontmatter format](https://jekyllrb.com/docs/front-matter/). ## Reviewer Questions + Do we want to add a CI rule actually requiring tagged PRs to create/modify files in the correct directories, or is the message prompt enough? + Do we want to add a CI rule to lint the metadata, for example to enforce that the PR number is included in the files it modifies? |
||
|
Zachary Harrold
|
958c9bb652
|
Add no_std Library Example (#18333)
# Objective - Fixes #17506 - Fixes #16258 ## Solution - Added a new folder of examples, `no_std`, similar to the `mobile` folder. - Added a single example, `no_std_library`, which demonstrates how to make a `no_std` compatible Bevy library. - Added a new CI task, `check-compiles-no-std-examples`, which checks that `no_std` examples compile on `no_std` targets. - Added `bevy_platform_support::prelude` to `bevy::prelude`. ## Testing - CI --- ## Notes - I've structured the folders here to permit further `no_std` examples (e.g., GameBoy Games, ESP32 firmware, etc.), but I am starting with the simplest and least controversial example. - I've tried to be as clear as possible with the documentation for this example, catering to an audience who may not have even heard of `no_std` before. --------- Co-authored-by: Greeble <166992735+greeble-dev@users.noreply.github.com> |
||
|
Mads Marquart
|
e6a6c9fb4c
|
Link iOS example with rustc, and avoid C trampoline (#14780)
# Objective
On iOS:
- Allow `std` to do its runtime initialization.
- Avoid requiring the user to specify linked libraries and framework in
Xcode.
- Reduce the amount of work that `#[bevy_main]` does
- In the future we may also be able to eliminate the need for it on
Android, cc @daxpedda.
## Solution
We previously:
- Exposed an `extern "C" fn main_rs` entry point.
- Ran Cargo in a separate Xcode target as an external build system.
- Imported that as a dependency of `bevy_mobile_example.app`.
- Compiled a trampoline C file with Xcode that called `main_rs`.
- Linked that via. Xcode.
All of this is unnecessary; `rustc` is well capable of creating iOS
executables, the trick is just to place it at the correct location for
Xcode to understand it, namely `$TARGET_BUILD_DIR/$EXECUTABLE_PATH`
(places it in `bevy_mobile_example.app/bevy_mobile_example`).
Note: We might want to wait with the changes to `#[bevy_main]` until the
problem is resolved on Android too, to make the migration easier.
## Testing
Open the Xcode project, and build for an iOS target.
---
## Migration Guide
**If you have been building your application for iOS:**
Previously, the `#[bevy_main]` attribute created a `main_rs` entry point
that most Xcode templates were using to run your Rust code from C. This
was found to be unnecessary, as you can simply let Rust build your
application as a binary, and run that directly.
You have two options for dealing with this:
If you've added further C code and Xcode customizations, or it makes
sense for your use-case to continue link with Xcode, you can revert to
the old behaviour by adding `#[no_mangle] extern "C" main_rs() { main()
}` to your `main.rs`. Note that the old approach of linking a static
library prevents the Rust standard library from doing runtime
initialization, so certain functionality provided by `std` might be
unavailable (stack overflow handlers, stdout/stderr flushing and other
such functionality provided by the initialization routines).
The other, preferred option is to remove your "compile" and "link" build
phases, and instead replace it with a "run script" phase that invokes
`cargo build --bin ...`, and moves the built binary to the Xcode path
`$TARGET_BUILD_DIR/$EXECUTABLE_PATH`. An example of how to do this can
be viewed at [INSERT LINK TO UPDATED EXAMPLE PROJECT].
To make the debugging experience in Xcode nicer after this, you might
also want to consider either enabling `panic = "abort"` or to set a
breakpoint on the `rust_panic` symbol.
---------
Co-authored-by: François Mockers <mockersf@gmail.com>
Co-authored-by: François Mockers <francois.mockers@vleue.com>
|
||
|
dependabot[bot]
|
c821eda853
|
Bump crate-ci/typos from 1.30.1 to 1.30.2 (#18354)
Bumps [crate-ci/typos](https://github.com/crate-ci/typos) from 1.30.1 to 1.30.2. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/crate-ci/typos/releases">crate-ci/typos's releases</a>.</em></p> <blockquote> <h2>v1.30.2</h2> <h2>[1.30.2] - 2025-03-10</h2> <h3>Features</h3> <ul> <li>Add <code>--highlight-words</code> and <code>--highlight-identifiers</code> for easier debugging of config</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/crate-ci/typos/blob/master/CHANGELOG.md">crate-ci/typos's changelog</a>.</em></p> <blockquote> <h2>[1.30.2] - 2025-03-10</h2> <h3>Features</h3> <ul> <li>Add <code>--highlight-words</code> and <code>--highlight-identifiers</code> for easier debugging of config</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
François Mockers
|
6b61e38011
|
update superlinter (#18320)
# Objective - super-linter uses an old version in CI and wasn't updated for the last two years ## Solution - Update super-linter |
||
|
dependabot[bot]
|
67c61d115d
|
Bump crate-ci/typos from 1.30.0 to 1.30.1 (#18227)
Bumps [crate-ci/typos](https://github.com/crate-ci/typos) from 1.30.0 to 1.30.1. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/crate-ci/typos/releases">crate-ci/typos's releases</a>.</em></p> <blockquote> <h2>v1.30.1</h2> <h2>[1.30.1] - 2025-03-04</h2> <h3>Features</h3> <ul> <li><em>(action)</em> Create <code>v1</code> tag</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/crate-ci/typos/blob/master/CHANGELOG.md">crate-ci/typos's changelog</a>.</em></p> <blockquote> <h2>[1.30.1] - 2025-03-04</h2> <h3>Features</h3> <ul> <li><em>(action)</em> Create <code>v1</code> tag</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
François Mockers
|
2a2e0a8555
|
Fix CI comment workflow after 18196 (#18217)
# Objective - I messed up in #18196 and broke the CI comment workflow ## Solution - Use the correct way to check a step |
||
|
François Mockers
|
4cd014384f
|
action shouldn't comment on a pr if last comment is from action (#18196)
# Objective - While a PR is in work, if several commits fail and trigger a comment from the action, this can create a lot of comments from actions with low value - Noticed on https://github.com/bevyengine/bevy/pull/18139 ## Solution - If last comment on a PR is from an action, don't add a new comment --------- Co-authored-by: Martín Maita <47983254+mnmaita@users.noreply.github.com> |
||
|
Zachary Harrold
|
cc69fdd0c6
|
Add no_std support to bevy (#17955)
# Objective - Fixes #15460 (will open new issues for further `no_std` efforts) - Supersedes #17715 ## Solution - Threaded in new features as required - Made certain crates optional but default enabled - Removed `compile-check-no-std` from internal `ci` tool since GitHub CI can now simply check `bevy` itself now - Added CI task to check `bevy` on `thumbv6m-none-eabi` to ensure `portable-atomic` support is still valid [^1] [^1]: This may be controversial, since it could be interpreted as implying Bevy will maintain support for `thumbv6m-none-eabi` going forward. In reality, just like `x86_64-unknown-none`, this is a [canary](https://en.wiktionary.org/wiki/canary_in_a_coal_mine) target to make it clear when `portable-atomic` no longer works as intended (fixing atomic support on atomically challenged platforms). If a PR comes through and makes supporting this class of platforms impossible, then this CI task can be removed. I however wager this won't be a problem. ## Testing - CI --- ## Release Notes Bevy now has support for `no_std` directly from the `bevy` crate. Users can disable default features and enable a new `default_no_std` feature instead, allowing `bevy` to be used in `no_std` applications and libraries. ```toml # Bevy for `no_std` platforms bevy = { version = "0.16", default-features = false, features = ["default_no_std"] } ``` `default_no_std` enables certain required features, such as `libm` and `critical-section`, and as many optional crates as possible (currently just `bevy_state`). For atomically-challenged platforms such as the Raspberry Pi Pico, `portable-atomic` will be used automatically. For library authors, we recommend depending on `bevy` with `default-features = false` to allow `std` and `no_std` users to both depend on your crate. Here are some recommended features a library crate may want to expose: ```toml [features] # Most users will be on a platform which has `std` and can use the more-powerful `async_executor`. default = ["std", "async_executor"] # Features for typical platforms. std = ["bevy/std"] async_executor = ["bevy/async_executor"] # Features for `no_std` platforms. libm = ["bevy/libm"] critical-section = ["bevy/critical-section"] [dependencies] # We disable default features to ensure we don't accidentally enable `std` on `no_std` targets, for example. bevy = { version = "0.16", default-features = false } ``` While this is verbose, it gives the maximum control to end-users to decide how they wish to use Bevy on their platform. We encourage library authors to experiment with `no_std` support. For libraries relying exclusively on `bevy` and no other dependencies, it may be as simple as adding `#![no_std]` to your `lib.rs` and exposing features as above! Bevy can also provide many `std` types, such as `HashMap`, `Mutex`, and `Instant` on all platforms. See `bevy::platform_support` for details on what's available out of the box! ## Migration Guide - If you were previously relying on `bevy` with default features disabled, you may need to enable the `std` and `async_executor` features. - `bevy_reflect` has had its `bevy` feature removed. If you were relying on this feature, simply enable `smallvec` and `smol_str` instead. --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com> |
||
|
François Mockers
|
8f85d4e598
|
rendering regression: mention in pr comment that the solution could be to update the pr (#18153)
# Objective - When a PR gets merged that modifies the rendering screenshots, the main reference will be updated - Every in-flight PR will then "fail" rendering change detection as they come from an outdated main branch ## Solution - Suggest updating the PR to the latest main branch |
||
|
François Mockers
|
019a6fde25
|
testbed for UI (#18091)
# Objective - have a testbed for UI ## Solution - move previous `ui` example to `full_ui` - add a testbed ui with several scenes - `ui_layout_rounding` is one of those scenes, so remove it as a standalone example the previous `ui` / new `full_ui` is I think still useful as it has some things like scroll, debug ui that are not shown anywhere else |
||
|
Alice Cecile
|
3be01c4d0f
|
Fix label name for Deliberate-Rendering-Change CI (#18118)
# Objective The label added in #18064 is the wrong color! It should be an `M-` (meta) label, not an `S-` (status) label! ## Solution - Rename the label in the comment that gets left to `M-Deliberate-Rendering-Change` - Also make the job check for the right label 🤦🏽♀️ Once this is approved and ready to merge, I'll rename the label on Github to match. |
||
|
Rob Parrett
|
36cb64b382
|
Bump typos to 1.30.0 (#18097)
# Objective Update `typos` and fix newly detected typos. [Changelog](https://github.com/crate-ci/typos/blob/master/CHANGELOG.md#1300---2025-03-01) (just a dictionary update releases) ## Solution Fix em - Describe the solution used to achieve the objective above. ## Testing CI |
||
|
François Mockers
|
0122b85cc3
|
comment on PR when example job finds changes (#18064)
# Objective - Comment on PR when getting a rendering change ## Solution - When something changes in the rendering check CI, add a comment on the PR to check the results - Suggest adding the label `S-Deliberate-Rendering-Change` if it's expected - Don't comment if the label is already present --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com> |
||
|
François Mockers
|
2f633c18ba
|
Split example runs to their own GitHub workflow (#18039)
# Objective - next step for #15918 ## Solution - Move jobs for macOS, Linux and Windows to their own workflow - Remove running on push to `main` from workflows CI and validation |
||
|
Brezak
|
5961df7c89
|
Automatically close weekly ci issue if weekly ci succeeds (#18016)
# Objective It's not always obvious when the issue created by the weekly CI run is safe to close. ## Solution Automatically close it when a weekly CI run succeeds so it doesn't get forgotten. ## Testing Hope. |
||
|
dependabot[bot]
|
0855a0e8ad
|
Bump crate-ci/typos from 1.29.7 to 1.29.9 (#18012)
Bumps [crate-ci/typos](https://github.com/crate-ci/typos) from 1.29.7 to 1.29.9. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/crate-ci/typos/releases">crate-ci/typos's releases</a>.</em></p> <blockquote> <h2>v1.29.9</h2> <h2>[1.29.9] - 2025-02-20</h2> <h3>Fixes</h3> <ul> <li><em>(action)</em> Correctly get binary for some aarch64 systems</li> </ul> <h2>v1.29.8</h2> <h2>[1.29.8] - 2025-02-19</h2> <h3>Features</h3> <ul> <li>Attempt to build Linux aarch64 binaries</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/crate-ci/typos/blob/master/CHANGELOG.md">crate-ci/typos's changelog</a>.</em></p> <blockquote> <h2>[1.29.9] - 2025-02-20</h2> <h3>Fixes</h3> <ul> <li><em>(action)</em> Correctly get binary for some aarch64 systems</li> </ul> <h2>[1.29.8] - 2025-02-19</h2> <h3>Features</h3> <ul> <li>Attempt to build Linux aarch64 binaries</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
Zachary Harrold
|
5241e09671
|
Upgrade to Rust Edition 2024 (#17967)
# Objective - Fixes #17960 ## Solution - Followed the [edition upgrade guide](https://doc.rust-lang.org/edition-guide/editions/transitioning-an-existing-project-to-a-new-edition.html) ## Testing - CI --- ## Summary of Changes ### Documentation Indentation When using lists in documentation, proper indentation is now linted for. This means subsequent lines within the same list item must start at the same indentation level as the item. ```rust /* Valid */ /// - Item 1 /// Run-on sentence. /// - Item 2 struct Foo; /* Invalid */ /// - Item 1 /// Run-on sentence. /// - Item 2 struct Foo; ``` ### Implicit `!` to `()` Conversion `!` (the never return type, returned by `panic!`, etc.) no longer implicitly converts to `()`. This is particularly painful for systems with `todo!` or `panic!` statements, as they will no longer be functions returning `()` (or `Result<()>`), making them invalid systems for functions like `add_systems`. The ideal fix would be to accept functions returning `!` (or rather, _not_ returning), but this is blocked on the [stabilisation of the `!` type itself](https://doc.rust-lang.org/std/primitive.never.html), which is not done. The "simple" fix would be to add an explicit `-> ()` to system signatures (e.g., `|| { todo!() }` becomes `|| -> () { todo!() }`). However, this is _also_ banned, as there is an existing lint which (IMO, incorrectly) marks this as an unnecessary annotation. So, the "fix" (read: workaround) is to put these kinds of `|| -> ! { ... }` closuers into variables and give the variable an explicit type (e.g., `fn()`). ```rust // Valid let system: fn() = || todo!("Not implemented yet!"); app.add_systems(..., system); // Invalid app.add_systems(..., || todo!("Not implemented yet!")); ``` ### Temporary Variable Lifetimes The order in which temporary variables are dropped has changed. The simple fix here is _usually_ to just assign temporaries to a named variable before use. ### `gen` is a keyword We can no longer use the name `gen` as it is reserved for a future generator syntax. This involved replacing uses of the name `gen` with `r#gen` (the raw-identifier syntax). ### Formatting has changed Use statements have had the order of imports changed, causing a substantial +/-3,000 diff when applied. For now, I have opted-out of this change by amending `rustfmt.toml` ```toml style_edition = "2021" ``` This preserves the original formatting for now, reducing the size of this PR. It would be a simple followup to update this to 2024 and run `cargo fmt`. ### New `use<>` Opt-Out Syntax Lifetimes are now implicitly included in RPIT types. There was a handful of instances where it needed to be added to satisfy the borrow checker, but there may be more cases where it _should_ be added to avoid breakages in user code. ### `MyUnitStruct { .. }` is an invalid pattern Previously, you could match against unit structs (and unit enum variants) with a `{ .. }` destructuring. This is no longer valid. ### Pretty much every use of `ref` and `mut` are gone Pattern binding has changed to the point where these terms are largely unused now. They still serve a purpose, but it is far more niche now. ### `iter::repeat(...).take(...)` is bad New lint recommends using the more explicit `iter::repeat_n(..., ...)` instead. ## Migration Guide The lifetimes of functions using return-position impl-trait (RPIT) are likely _more_ conservative than they had been previously. If you encounter lifetime issues with such a function, please create an issue to investigate the addition of `+ use<...>`. ## Notes - Check the individual commits for a clearer breakdown for what _actually_ changed. --------- Co-authored-by: François Mockers <francois.mockers@vleue.com> |
||
|
François Mockers
|
e4e70a7473
|
don't update mesa for wasm example run (#17999)
# Objective - running wasm examples in CI currently timeout, this blocks merging PRs ## Solution - Don't update mesa but uses the version provided by the latest ubuntu - Alternative to #17998 ## Testing run in a docker container: `docker run --rm -it ubuntu` ``` apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install --no-install-recommends -y curl git software-properties-common nodejs npm build-essential curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y . "$HOME/.cargo/env" rustup target install wasm32-unknown-unknown curl -L --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/cargo-bins/cargo-binstall/main/install-from-binstall-release.sh | bash cargo binstall wasm-bindgen-cli -y git clone https://github.com/bevyengine/bevy cd bevy cd .github/start-wasm-example npm install npx playwright install --with-deps cd ../.. python3 -m http.server --directory examples/wasm & xvfb-run cargo run -p build-wasm-example -- --browsers firefox --frames 25 --test 2d_shapes ``` |
||
|
Rob Parrett
|
fb1e829294
|
Bump typos to 1.29.7 (#17902)
# Objective Alternative to #17894 that also cleans up the workaround from the previous version ## Solution Bump version and remove entry from `typos` config |
||
|
Rob Parrett
|
2760692f88
|
Update typos to 1.29.6 (#17850)
# Objective Update typos, fix new typos. 1.29.6 was just released to fix an [issue](https://github.com/crate-ci/typos/issues/1228) where January's corrections were not included in the binaries for the last release. Reminder: typos can be tossed in the monthly [non-critical corrections issue](https://github.com/crate-ci/typos/issues/1221). ## Solution I chose to allow `implementors`, because a good argument seems to be being made [here](https://github.com/crate-ci/typos/issues/1226) and there is now a PR to address that. ## Discussion Should I exclude `bevy_mikktspace`? At one point I think we had an informal policy of "don't mess with mikktspace until https://github.com/bevyengine/bevy/pull/9050 is merged" but it doesn't seem like that is likely to be merged any time soon. I think these particular corrections in mikktspace are fine because - The same typo mistake seems to have been fixed in that PR - The entire file containing these corrections was deleted in that PR ## Typo of the Month correspindong -> corresponding |
||
|
SpecificProtagonist
|
5b0d898866
|
Trait tags on docs.rs (#17758)
# Objective Bevy's ECS provides several core traits such as `Component`, `SystemParam`, etc that determine where a type can be used. When reading the docs, this currently requires scrolling down to and scanning the "Trait Implementations" section. Make these core traits more visible. ## Solution Add a color-coded labels below the type heading denoting the following types: - `Component` - immutable components are labeled as such - `Resource` - `Asset` - `Event` - `Plugin` & `PluginGroup` - `ScheduleLabel` & `SystemSet` - `SystemParam` As docs.rs does not provide an option for post-processing the html, these are added via JS with traits implementations being detected by scanning the DOM. Rustdoc's html output is unstable, which could potentially lead to this detection (or the adding of the labels) to break, however it only needs to work when a new release is deployed and falls back to the status quo of not displaying these labels. Idea by JMS55, implementation by Jondolf (see https://github.com/Jondolf/bevy_docs_extension_demo/). ## Testing Run this in Bevy's root folder: ```bash RUSTDOCFLAGS="--html-after-content docs-rs/trait-tags.html --cfg docsrs_dep" RUSTFLAGS="--cfg docsrs_dep" cargo doc --no-deps -p <some_bevy_package> ``` --- ## Showcase Check it out on [docs.rs](https://docs.rs/bevy_docs_extension_demo/0.1.1/bevy_docs_extension_demo/struct.TestAllTraits.html)  ## Release Notes On docs.rs, Bevy now displays labels indicating which core traits a type implements:  If you want to add these to your own crate, check out [these instructions](https://github.com/bevyengine/bevy/blob/main/docs-rs#3rd-party-crates). --------- Co-authored-by: Joona Aalto <jondolf.dev@gmail.com> Co-authored-by: Carter Weinberg <weinbergcarter@gmail.com> |
||
|
François Mockers
|
7d141829be
|
run example in CI on windows using static dxc (#17783)
# Objective - Run more things on windows ## Solution - With the update of wgpu and the statically linked dxc, examples now run on windows in CI |
||
|
dependabot[bot]
|
d9df371ef2
|
Bump crate-ci/typos from 1.29.4 to 1.29.5 (#17655)
Bumps [crate-ci/typos](https://github.com/crate-ci/typos) from 1.29.4 to 1.29.5. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/crate-ci/typos/releases">crate-ci/typos's releases</a>.</em></p> <blockquote> <h2>v1.29.5</h2> <h2>[1.29.5] - 2025-01-30</h2> <h3>Internal</h3> <ul> <li>Update a dependency</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/crate-ci/typos/blob/master/CHANGELOG.md">crate-ci/typos's changelog</a>.</em></p> <blockquote> <h2>[1.29.5] - 2025-01-30</h2> <h3>Internal</h3> <ul> <li>Update a dependency</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
François Mockers
|
33c5e0bc96
|
Tiny ci improvements (#17627)
# Objective - make CI a bit faster without losing anything ## Solution - Always disable incremental compilation. This was done in a few jobs, just do it everywhere - Also disable debug info. This should reduce target folder a bit, reducing cache size and upload duration |
||
|
François Mockers
|
e57f73207e
|
Smarter testbeds (#17573)
# Objective - Improve CI when testing rendering by having smarter testbeds ## Solution - CI testing no longer need a config file and will run with a default config if not found - It is now possible to give a name to a screenshot instead of just a frame number - 2d and 3d testbeds are now driven from code - a new system in testbed will watch for state changed - on state changed, trigger a screenshot 100 frames after (so that the scene has time to render) with the name of the scene - when the screenshot is taken (`Captured` component has been removed), switch scene - this means less setup to run a testbed (no need for a config file), screenshots have better names, and it's faster as we don't wait 100 frames for the screenshot to be taken ## Testing - `cargo run --example testbed_2d --features bevy_ci_testing` |
||
|
Rob Parrett
|
edb34cd2dd
|
Run example validation jobs on ubuntu-latest (#17169)
# Objective Fixes #17164 ## Solution - Switch to `ubuntu-latest` - Remove `libegl1-mesa`. It seems that whatever this was providing is now covered by other deps or their deps? ## Testing Tested [over here](https://github.com/rparrett/bevy/pull/21) by commenting out workflow `if` condition. |
||
|
Benjamin Brienen
|
8baf4e5b2c
|
msrv needs build (#17156)
# Objective My previous PR is causing the github bot to comment whenver a PR build fails. This is a mistake. ## Solution msrv should depend on build succeeding |
||
|
François Mockers
|
cc4aace1aa
|
Fix workflows for version bump (#17162)
# Objective - Version bump workflow fails due to a permission issue - Fixes #17153 ## Solution - Add the required permissions - Also remove workflow not used anymore since the RC |
||
|
François Mockers
|
20c1a7e9ce
|
remove daily mobile jobs (#17163)
# Objective - Daily mobile job has been failing for a long time - It's in a weird state of hard to fix without knowing some passwords, hard to monitor, and not that used anyway - I keep a working version in the example runner repository that runs more often ## Solution - Remove the workflow from the Bevy repo |
||
|
Benjamin Brienen
|
39f38a191e
|
Add -D warnings in a few steps (#17081)
# Objective I missed a couple checks in #17011 ## Solution Add env ## Testing CI |
||
|
Rob Parrett
|
651b22f31f
|
Update typos (#17126)
# Objective Use the latest version of `typos` and fix the typos that it now detects # Additional Info By the way, `typos` has a "low priority typo suggestions issue" where we can throw typos we find that `typos` doesn't catch. (This link may go stale) https://github.com/crate-ci/typos/issues/1200 |
||
|
Rob Parrett
|
effc9df572
|
Show working urls to screenshot comparisons in output (#17125)
# Objective When a PR introduces changes that result in differences in the rendering one of the "testbeds," contributors get a nice email informing them about a [failed workflow run](https://github.com/bevyengine/bevy/actions/runs/12599884045/job/35117729566). However, this email contains links that just go to a json blob which isn't as helpful as it could be. If you squint real hard, you can figure out which testbed failed and at which frame the screenshot took place. Not ideal. This changes the urls presented as output in that workflow so that they lead to the actual screenshot comparison screen on pixel-eagle.  <img width="753" alt="image" src="https://github.com/user-attachments/assets/7d39de37-8cff-4db3-8fbc-288e482d876c" /> ## Solution Change the urls in the output from e.g. https://pixel-eagle.vleue.com/B04F67C0-C054-4A6F-92EC-F599FEC2FD1D/runs/4591/compare/4568 To https://pixel-eagle.com/project/B04F67C0-C054-4A6F-92EC-F599FEC2FD1D/run/4591/compare/4568 Without messing with any of the URLs involved in uploading the screenshots. ## Testing I have not tested this (yet) beyond manual testing of the new URL structure. I suspect it's not possible to test in a fork. |
||
|
Tristan Murphy
|
afed4e27d1
|
small documentation update and issue template fix (#17054)
# Objective Fix some outdated `bevy_state` documentation examples. ## Solution - updated some doc examples in `bevy_state` that hadn't been updated with the API. - fixed an outdated link in the documentation issue template that referred to a 404 page instead of the contribution guide. ## Testing No necessary testing aside from the usual doctests. --- ## Showcase N/A ## Migration Guide N/A --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com> |