# Objective
- Fixes#6370
- Closes#6581
## Solution
- Added the following lints to the workspace:
- `std_instead_of_core`
- `std_instead_of_alloc`
- `alloc_instead_of_core`
- Used `cargo +nightly fmt` with [item level use
formatting](https://rust-lang.github.io/rustfmt/?version=v1.6.0&search=#Item%5C%3A)
to split all `use` statements into single items.
- Used `cargo clippy --workspace --all-targets --all-features --fix
--allow-dirty` to _attempt_ to resolve the new linting issues, and
intervened where the lint was unable to resolve the issue automatically
(usually due to needing an `extern crate alloc;` statement in a crate
root).
- Manually removed certain uses of `std` where negative feature gating
prevented `--all-features` from finding the offending uses.
- Used `cargo +nightly fmt` with [crate level use
formatting](https://rust-lang.github.io/rustfmt/?version=v1.6.0&search=#Crate%5C%3A)
to re-merge all `use` statements matching Bevy's previous styling.
- Manually fixed cases where the `fmt` tool could not re-merge `use`
statements due to conditional compilation attributes.
## Testing
- Ran CI locally
## Migration Guide
The MSRV is now 1.81. Please update to this version or higher.
## Notes
- This is a _massive_ change to try and push through, which is why I've
outlined the semi-automatic steps I used to create this PR, in case this
fails and someone else tries again in the future.
- Making this change has no impact on user code, but does mean Bevy
contributors will be warned to use `core` and `alloc` instead of `std`
where possible.
- This lint is a critical first step towards investigating `no_std`
options for Bevy.
---------
Co-authored-by: François Mockers <francois.mockers@vleue.com>
# Objective
It looks like running `compile_fail_utils::test` on an invalid path just
skips the test. I'm not sure why `ui_test` doesn't fail the test, but it
seems pretty easy to accidentally cause a test to be skipped (I
experienced
[this](https://github.com/bevyengine/bevy/pull/14813#discussion_r1721880973)
while doing some refactoring on `bevy_reflect`).
## Solution
Check to make sure the given path exists before continuing on with the
tests.
Alternatively, we could look into seeing why this doesn't work properly
upstream. But I figured this solution was simple enough just to
implement directly without having to worry about updating `ui_test`.
## Testing
To verify that this works as expected `cd` into
`crates/bevy_reflect/compile_fail`. Then run the following:
```
cargo test --target-dir ../../../target
```
All compile fail tests should pass. Now edit the path used in
`crates/bevy_reflect/compile_fail/tests/derive.rs`. For example:
```diff
fn main() -> compile_fail_utils::ui_test::Result<()> {
- compile_fail_utils::test("reflect_derive", "tests/reflect_derive")
+ compile_fail_utils::test("reflect_derive", "tests/does_not_exist")
}
```
Run the tests again:
```
cargo test --target-dir ../../../target
```
Verify the test fails with an error like:
```
Error: path does not exist: "tests/does_not_exist"
```
# Objective
Fixes#14782
## Solution
Enable the lint and fix all upcoming hints (`--fix`). Also tried to
figure out the false-positive (see review comment). Maybe split this PR
up into multiple parts where only the last one enables the lint, so some
can already be merged resulting in less many files touched / less
potential for merge conflicts?
Currently, there are some cases where it might be easier to read the
code with the qualifier, so perhaps remove the import of it and adapt
its cases? In the current stage it's just a plain adoption of the
suggestions in order to have a base to discuss.
## Testing
`cargo clippy` and `cargo run -p ci` are happy.
# Objective
- CI broke after #14284 because of the `cursor_options` rename
## Solution
- Update the broken patch
## Testing
- Patch tested with `git apply`.
# Objective
- Dynamic plugins were deprecated in #13080 due to being unsound. The
plan was to deprecate them in 0.14 and remove them in 0.15.
## Solution
- Remove all dynamic plugin functionality.
- Update documentation to reflect this change.
---
## Migration Guide
Dynamic plugins were deprecated in 0.14 for being unsound, and they have
now been fully removed. Please consider using the alternatives listed in
the `bevy_dynamic_plugin` crate documentation, or worst-case scenario
you may copy the code from 0.14.
# Objective
Fixes https://github.com/bevyengine/bevy-website/issues/1558
Followup to #12348
For the website pages extra link, it needs kebab case for the category
name and a trailing forward slash to make the link for the Bevy website
correct and not have unnecessary redirections.
## Solution
Changes the category name to kebab case for the extra link, and adds a
trailing forward slash to the link.
## Testing
I have tested these changes.
Clone my fork with the changes in `bevy-website/generate-wasm-examples/`
then `cd bevy && git switch bevy-website/1558_fix_beautify_example_links
&& cd ..` and then `./generate_wasm_examples.sh` to generate examples.
Afterwards runs `zola serve` and go to `http://127.0.0.1:1111/examples`
and hover over or inspect the cards links / anchors to see that the link
is now correct, click on any of the cards to see that there is no
redirects.
# Objective
- Fix issue #2611
## Solution
- Add `--generate-link-to-definition` to all the `rustdoc-args` arrays
in the `Cargo.toml`s (for docs.rs)
- Add `--generate-link-to-definition` to the `RUSTDOCFLAGS` environment
variable in the docs workflow (for dev-docs.bevyengine.org)
- Document all the workspace crates in the docs workflow (needed because
otherwise only the source code of the `bevy` package will be included,
making the argument useless)
- I think this also fixes#3662, since it fixes the bug on
dev-docs.bevyengine.org, while on docs.rs it has been fixed for a while
on their side.
---
## Changelog
- The source code viewer on docs.rs now includes links to the
definitions.
# Objective
- The default values hard coded in the showcase script may not make
sense depending on your hardware
## Solution
- Let them be customised from the CLI
---------
Co-authored-by: BD103 <59022059+BD103@users.noreply.github.com>
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
Co-authored-by: Rob Parrett <robparrett@gmail.com>
# Objective
The github action summary titles every compile test group as
`compile_fail_utils`.
## Solution
Manually specify group names for compile fail tests.
## Testing
- Wait for compile fail tests to run.
- Observe the generated summary.
# Objective
- Bevy currently has lot of invalid intra-doc links, let's fix them!
- Also make CI test them, to avoid future regressions.
- Helps with #1983 (but doesn't fix it, as there could still be explicit
links to docs.rs that are broken)
## Solution
- Make `cargo r -p ci -- doc-check` check fail on warnings (could also
be changed to just some specific lints)
- Manually fix all the warnings (note that in some cases it was unclear
to me what the fix should have been, I'll try to highlight them in a
self-review)
# Objective
- After #13908, shaders imported are collected
- this is done with a hashset, so order is random between executions
## Solution
- Don't use a hashset, and keep the order they were found in the example
# Objective
Add extra metadata for the shader examples that contains the location of
their associated shader file(s). This is to be used for the bevy website
shader examples so that the shader code is underneath the rust code.
## Solution
Parse the example rust files for mentions of `.wgsl`, `.frag`, and
`.vert`, then append the found paths to a field called
`shader_code_paths` in the generated `index.md`s for each shader
example.
# Objective
This is the first of a series of PRs intended to begin the upstreaming
process for `bevy_mod_picking`. The purpose of this PR is to:
+ Create the new `bevy_picking` crate
+ Upstream `CorePlugin` as `PickingPlugin`
+ Upstream the core pointer and backend abstractions.
This code has been ported verbatim from the corresponding files in
[bevy_picking_core](https://github.com/aevyrie/bevy_mod_picking/tree/main/crates/bevy_picking_core/src)
with a few tiny naming and docs tweaks.
The work here is only an initial foothold to get the up-streaming
process started in earnest. We can do refactoring and improvements once
this is in-tree.
---------
Co-authored-by: Aevyrie <aevyrie@gmail.com>
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective
- CI on main has been failing since #13640 was merged.
- Here's the [offending
run](https://github.com/bevyengine/bevy/actions/runs/9352635857/job/25741242787).
- One of the patch files is out of date, so it failed in the validation
check.
## Solution
- Regenerate the patch file. (The location has been moved to
`cluster/mod.rs`.)
## Testing
- Run `git apply
tools/example-showcase/reduce-light-cluster-config.patch`
- It should change `bevy_pbr/src/cluster/mod.rs` on line 239, decreasing
`total` and `z_slices`.
- CI's validation checks should also verify that this works, though only
after it gets merged.
# Objective
- Upgrade winit to v0.30
- Fixes https://github.com/bevyengine/bevy/issues/13331
## Solution
This is a rewrite/adaptation of the new trait system described and
implemented in `winit` v0.30.
## Migration Guide
The custom UserEvent is now renamed as WakeUp, used to wake up the loop
if anything happens outside the app (a new
[custom_user_event](https://github.com/bevyengine/bevy/pull/13366/files#diff-2de8c0a8d3028d0059a3d80ae31b2bbc1cde2595ce2d317ea378fe3e0cf6ef2d)
shows this behavior.
The internal `UpdateState` has been removed and replaced internally by
the AppLifecycle. When changed, the AppLifecycle is sent as an event.
The `UpdateMode` now accepts only two values: `Continuous` and
`Reactive`, but the latter exposes 3 new properties to enable reactive
to device, user or window events. The previous `UpdateMode::Reactive` is
now equivalent to `UpdateMode::reactive()`, while
`UpdateMode::ReactiveLowPower` to `UpdateMode::reactive_low_power()`.
The `ApplicationLifecycle` has been renamed as `AppLifecycle`, and now
contains the possible values of the application state inside the event
loop:
* `Idle`: the loop has not started yet
* `Running` (previously called `Started`): the loop is running
* `WillSuspend`: the loop is going to be suspended
* `Suspended`: the loop is suspended
* `WillResume`: the loop is going to be resumed
Note: the `Resumed` state has been removed since the resumed app is just
running.
Finally, now that `winit` enables this, it extends the `WinitPlugin` to
support custom events.
## Test platforms
- [x] Windows
- [x] MacOs
- [x] Linux (x11)
- [x] Linux (Wayland)
- [x] Android
- [x] iOS
- [x] WASM/WebGPU
- [x] WASM/WebGL2
## Outstanding issues / regressions
- [ ] iOS: build failed in CI
- blocking, but may just be flakiness
- [x] Cross-platform: when the window is maximised, changes in the scale
factor don't apply, to make them apply one has to make the window
smaller again. (Re-maximising keeps the updated scale factor)
- non-blocking, but good to fix
- [ ] Android: it's pretty easy to quickly open and close the app and
then the music keeps playing when suspended.
- non-blocking but worrying
- [ ] Web: the application will hang when switching tabs
- Not new, duplicate of https://github.com/bevyengine/bevy/issues/13486
- [ ] Cross-platform?: Screenshot failure, `ERROR present_frames:
wgpu_core::present: No work has been submitted for this frame before`
taking the first screenshot, but after pressing space
- non-blocking, but good to fix
---------
Co-authored-by: François <francois.mockers@vleue.com>
# Objective
- Ever since #13177, the `check-example-showcase-patches-still-work` job
has been failing in the merge queue.
- Specifically, the `asset-source-website.patch` file which modifies
`bevy_asset`'s `lib.rs`.
## Solution
- Re-create the patch.
- Due to new content being added, the line numbers were off.
- Also, turns out that `typos` was checking patch files. This turned
into a CI error, so I disabled that too. Patches shouldn't really be
modified manually, the original source should be. (Also it was erroring
on the commit hash.)
## Testing
- Test the new patch works by running `git apply
tools/example-showcase/asset-source-website.patch`.
- Verify the merge queue passes with the
`check-example-showcase-patches-still-work` job succeeding.
# Objective
Extracts the state mechanisms into a new crate called "bevy_state".
This comes with a few goals:
- state wasn't really an inherent machinery of the ecs system, and so
keeping it within bevy_ecs felt forced
- by mixing it in with bevy_ecs, the maintainability of our more robust
state system was significantly compromised
moving state into a new crate makes it easier to encapsulate as it's own
feature, and easier to read and understand since it's no longer a
single, massive file.
## Solution
move the state-related elements from bevy_ecs to a new crate
## Testing
- Did you test these changes? If so, how? all the automated tests
migrated and passed, ran the pre-existing examples without changes to
validate.
---
## Migration Guide
Since bevy_state is now gated behind the `bevy_state` feature, projects
that use state but don't use the `default-features` will need to add
that feature flag.
Since it is no longer part of bevy_ecs, projects that use bevy_ecs
directly will need to manually pull in `bevy_state`, trigger the
StateTransition schedule, and handle any of the elements that bevy_app
currently sets up.
---------
Co-authored-by: Kristoffer Søholm <k.soeholm@gmail.com>
# Objective
- Some of the "large" crates have sub-crates, usually for things such as
macros.
- For an example, see [`bevy_ecs_macros` at
`bevy_ecs/macros`](4f9f987099/crates/bevy_ecs/macros).
- The one crate that does not follow this convention is
[`bevy_reflect_derive`](4f9f987099/crates/bevy_reflect/bevy_reflect_derive),
which is in the `bevy_reflect/bevy_reflect_derive` folder and not
`bevy_reflect/derive` or `bevy_reflect/macros`.
## Solution
- Rename folder `bevy_reflect_derive` to `derive`.
- I chose to use `derive` instead of `macros` because the crate name
itself ends in `_derive`. (One of only two crates to actually use this
convention, funnily enough.)
## Testing
- Build and test `bevy_reflect` and `bevy_reflect_derive`.
- Apply the following patch to `publish.sh` to run it in `--dry-run`
mode, to test that the path has been successfully updated:
- If you have any security concerns about applying random diffs, feel
free to skip this step. Worst case scenario it fails and Cart has to
manually publish a few crates.
```bash
# Apply patch to make `publish.sh` *not* actually publish anything.
git apply path/to/foo.patch
# Make `publish.sh` executable.
chmod +x tools/publish.sh
# Execute `publish.sh`.
./tools/publish.sh
```
```patch
diff --git a/tools/publish.sh b/tools/publish.sh
index b020bad28..fbcc09281 100644
--- a/tools/publish.sh
+++ b/tools/publish.sh
@@ -49,7 +49,7 @@ crates=(
if [ -n "$(git status --porcelain)" ]; then
echo "You have local changes!"
- exit 1
+ # exit 1
fi
pushd crates
@@ -61,15 +61,15 @@ do
cp ../LICENSE-APACHE "$crate"
pushd "$crate"
git add LICENSE-MIT LICENSE-APACHE
- cargo publish --no-verify --allow-dirty
+ cargo publish --no-verify --allow-dirty --dry-run
popd
- sleep 20
+ # sleep 20
done
popd
echo "Publishing root crate"
-cargo publish --allow-dirty
+cargo publish --allow-dirty --dry-run
echo "Cleaning local state"
git reset HEAD --hard
```
---
## Changelog
- Moved `bevy_reflect_derive` from
`crates/bevy_reflect/bevy_reflect_derive` to
`crates/bevy_reflect/derive`.
# Objective
- Follow-up of #13184 :)
- We use `ui_test` to test compiler errors for our custom macros.
- There are four crates related to compile fail tests
- `bevy_ecs_compile_fail_tests`, `bevy_macros_compile_fail_tests`, and
`bevy_reflect_compile_fail_tests`, which actually test the macros.
-
[`bevy_compile_test_utils`](64c1c65783/crates/bevy_compile_test_utils),
which provides helpers and common patterns for these tests.
- All of these crates reside within the `crates` directory.
- This can be confusing, especially for newcomers. All of the other
folders in `crates` are actual published libraries, except for these 4.
## Solution
- Move all compile fail tests to a `compile_fail` folder under their
corresponding crate.
- E.g. `crates/bevy_ecs_compile_fail_tests` would be moved to
`crates/bevy_ecs/compile_fail`.
- Move `bevy_compile_test_utils` to `tools/compile_fail_utils`.
There are a few benefits to this approach:
1. An internal testing detail is less intrusive (and confusing) for
those who just want to browse the public Bevy interface.
2. Follows a pre-existing approach of organizing related crates inside a
larger crate's folder.
- See `bevy_gizmos/macros` for an example.
4. Makes consistent the terms `compile_test`, `compile_fail`, and
`compile_fail_test` in code. It's all just `compile_fail` now, because
we are specifically testing the error messages on compiler failures.
- To be clear it can still be referred to by these terms in comments and
speech, just the names of the crates and the CI command are now
consistent.
## Testing
Run the compile fail CI command:
```shell
cargo run -p ci -- compile-fail
```
If it still passes, then my refactor was successful.
# Objective
- The report_details flag currently dumps everything at the root of the
repo which isn't ideal
- When running the tool locally it's useful to see the logs as they
appear
## Solution
- Add a flag to show the logs
- Write all the report files to a folder
# Objective
- Current config file is hard to extend
## Solution
- Instead of an hard coded list of field, the file now has a list of
`(frame, event)`, and will deal with know events (exiting or taking a
screenshot), or send an event for others that can be dealt by third
party plugins
# Objective
- #12755 introduced the need to download a file to run an example
- This means the example fails to run in CI without downloading that
file
## Solution
- Add a new metadata to examples "setup" that provides setup
instructions
- Replace the URL in the meshlet example to one that can actually be
downloaded
- example-showcase execute the setup before running an example
# Objective
- Many of the items in the `ci` tool use `pub(crate)`, which is
functionally equivalent to `pub` when the crate is not a library.
- A few items are missing documentation.
## Solution
- Make all `pub(crate)` items just `pub`.
- `pub` is easier to type and less obscure, and there's not harm from
this change.
- Add / modify documentation on `CI`, `Prepare`, and `PreparedCommand`.
# Objective
- The [`version`] field in `Cargo.toml` is optional for crates not
published on <https://crates.io>.
- We have several `publish = false` tools in this repository that still
have a version field, even when it's not useful.
[`version`]:
https://doc.rust-lang.org/cargo/reference/manifest.html#the-version-field
## Solution
- Remove the [`version`] field for all crates where `publish = false`.
- Update the description on a few crates and remove extra newlines as
well.
# Objective
- Currently all `ci` commands are in the `subcommands` module. This is
problematic when you want to implement actually subcommands (such as
`cargo r -p ci -- doc check`).
- All command modules include the `_command` suffix, which is redundant.
## Solution
- Move `commands` modules into root crate folder.
- Merge contents of `commands/mod.rs` into `main.rs`.
- Move `commands::subcommands` module into `commands` module.
- Remove the `_command` suffix from all `commands::subcommands` modules.
# Objective
- Ensure that all examples are scrapped for doc
## Solution
- Panic in the example tool when an example doesn't specify
`doc-scrape-examples`
- If an example must not be scrapped, it can set the value to false
# Objective
The CI tool currently parses input manually. This has worked fine, but
makes it just a bit more difficult to maintain and extend. Additionally,
it provides no usage help for devs wanting to run the tool locally.
It would be better if parsing was handled by a dedicated CLI library
like [`clap`](https://github.com/clap-rs/clap) or
[`argh`](https://github.com/google/argh).
## Solution
Use `argh` to parse command line input for CI.
`argh` was chosen over `clap` and other tools due to being more
lightweight and already existing in our dependency tree.
Using `argh`, the usage notes are generated automatically:
```
$ cargo run -p ci --quiet -- --help
Usage: ci [--keep-going] [<command>] [<args>]
The CI command line tool for Bevy.
Options:
--keep-going continue running commands even if one fails
--help display usage information
Commands:
lints Alias for running the `format` and `clippy` subcommands.
doc Alias for running the `doc-test` and `doc-check`
subcommands.
compile Alias for running the `compile-fail`, `bench-check`,
`example-check`, `compile-check`, and `test-check`
subcommands.
format Check code formatting.
clippy Check for clippy warnings and errors.
test Runs all tests (except for doc tests).
test-check Checks that all tests compile.
doc-check Checks that all docs compile.
doc-test Runs all doc tests.
compile-check Checks that the project compiles.
cfg-check Checks that the project compiles using the nightly compiler
with cfg checks enabled.
compile-fail Runs the compile-fail tests.
bench-check Checks that the benches compile.
example-check Checks that the examples compile.
```
This PR makes each subcommand more modular, allowing them to be called
from other subcommands. This also makes it much easier to extract them
out of `main.rs` and into their own dedicated modules.
Additionally, this PR improves failure output:
```
$ cargo run -p ci -- lints
...
One or more CI commands failed:
format: Please run 'cargo fmt --all' to format your code.
```
Including when run with the `--keep-going` flag:
```
$ cargo run -p ci -- --keep-going lints
...
One or more CI commands failed:
- format: Please run 'cargo fmt --all' to format your code.
- clippy: Please fix clippy errors in output above.
```
### Future Work
There are a lot of other things we could possibly clean up. I chose to
try and keep the API surface as unchanged as I could (for this PR at
least).
For example, now that each subcommand is an actual command, we can
specify custom arguments for each.
The `format` subcommand could include a `--check` (making the default
fun `cargo fmt` as normal). Or the `compile-fail` subcommand could
include `--ecs`, `--reflect`, and `--macros` flags for specifying which
set of compile fail tests to run.
The `--keep-going` flag could be split so that it doesn't do double-duty
where it also enables `--no-fail-fast` for certain commands. Or at least
make it more explicit via renaming or using alternative flags.
---
## Changelog
- Improved the CI CLI tool
- Now includes usage info with the `--help` option!
- [Internal] Cleaned up and refactored the `tools/ci` crate using the
`argh` crate
## Migration Guide
The CI tool no longer supports running multiple subcommands in a single
call. Users who are currently doing so will need to split them across
multiple commands:
```bash
# BEFORE
cargo run -p ci -- lints doc compile
# AFTER
cargo run -p ci -- lints && cargo run -p ci -- doc && cargo run -p ci -- compile
# or
cargo run -p ci -- lints; cargo run -p ci -- doc; cargo run -p ci -- compile
# or
cargo run -p ci -- lints
cargo run -p ci -- doc
cargo run -p ci -- compile
```
# Objective
- The CI tool is slowly getting more difficult to maintain and could use
a bit of refactoring.
## Solution
- Do a first pass of small improvements.
## For Reviewers
This PR is best reviewed commit-by-commit, because I separate it into a
collection of small changes. :)
# Objective
- There are several redundant imports in the tests and examples that are
not caught by CI because additional flags need to be passed.
## Solution
- Run `cargo check --workspace --tests` and `cargo check --workspace
--examples`, then fix all warnings.
- Add `test-check` to CI, which will be run in the check-compiles job.
This should catch future warnings for tests. Examples are already
checked, but I'm not yet sure why they weren't caught.
## Discussion
- Should the `--tests` and `--examples` flags be added to CI, so this is
caught in the future?
- If so, #12818 will need to be merged first. It was also a warning
raised by checking the examples, but I chose to split off into a
separate PR.
---------
Co-authored-by: François Mockers <francois.mockers@vleue.com>
# Objective
The current example showcase site URLs have white-space and caps in them
which looks ugly as an URL.
Fixes https://github.com/bevyengine/bevy-website/issues/736
## Solution
To fix this the example showcase tool now makes the category used for
the site sections lowercase, separated by a hyphen rather than
white-space, and without parentheses.
---------
Co-authored-by: Rob Parrett <robparrett@gmail.com>
Co-authored-by: vero <email@atlasdostal.com>
# Objective
The `example-showcase` command is failing to run.
```
cargo run --release -p example-showcase -- run --screenshot --in-ci
Updating crates.io index
Compiling example-showcase v0.14.0-dev (/Users/robparrett/src/bevy/tools/example-showcase)
Finished release [optimized] target(s) in 2.59s
Running `target/release/example-showcase run --screenshot --in-ci`
$ git apply --ignore-whitespace tools/example-showcase/remove-desktop-app-mode.patch
error: patch failed: crates/bevy_winit/src/winit_config.rs:29
error: crates/bevy_winit/src/winit_config.rs: patch does not apply
thread 'main' panicked at tools/example-showcase/src/main.rs:203:18:
called `Result::unwrap()` on an `Err` value: command exited with non-zero code `git apply --ignore-whitespace tools/example-showcase/remove-desktop-app-mode.patch`: 1
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
## Solution
Update `remove-desktop-app-mode.patch`.
# Objective
- `toml_edit` released a new patch that deprecates `Document`
- this warns when Bevy builds, and CI deny warns
## Solution
- fix deprecation warnings
# Objective
- Resolves#11309
## Solution
- Add `bevy_dev_tools` crate as a default feature.
- Add `DevToolsPlugin` and add it to an app if the `bevy_dev_tools`
feature is enabled.
`bevy_dev_tools` is reserved by @alice-i-cecile, should we wait until it
gets transferred to cart before merging?
---------
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
Co-authored-by: BD103 <59022059+BD103@users.noreply.github.com>
# Objective
- Make running CI locally relatively less painful by allowing
continuation after failure
- Fix#12206
## Solution
Previously, `ci` would halt after encounting a failure (or shortly
thereafter). For instance, if you ran `cargo run -p ci` and a single
test within a CI check failed somewhere in the middle, you would never
even reach many of the other tests within the check and certainly none
of the CI checks that came afterward. This was annoying; if I am fixing
issues with CI tests, I want to just see all of the issues up-front
instead of having to rerun CI every time I fix something to see the next
error.
Furthermore, it is not infrequent (because of subtle
configuration/system differences) to encounter spurious CI failures
locally; previously, when these occurred, they would make the process of
running CI largely pointless, since you would have to push your branch
in order to see your actual CI failures from the automated testing
service.
Now, when running `ci` locally, we have a couple new tools to ameliorate
these and provide a smoother experience:
- Firstly, there is a new optional flag `--keep-going` that can be
passed while calling `ci` (e.g. `cargo run -p ci -- doc --keep-going`).
It has the following effects:
- It causes the `--keep-going` flag to be passed to the script's `cargo
doc` and `cargo check` invocations, so that they do not stop when they
encounter an error in a single module; instead, they keep going (!) and
find errors subsequently.
- It causes the `--no-fail-fast` flag to be passed to the script's
`cargo test` invocations, to similar effect.
- Finally, it causes `ci` itself not to abort after a single check
fails; instead, it will run every check that was invoked.
Thus, for instance, `cargo run -p ci -- --keep-going` will run every CI
check even if it encounters intermediate failures, and every such check
will itself be run to completion.
- Secondly, we now allow multiple ordinary arguments to be passed to
`ci`. For instance, `cargo -p ci -- doc test` now executes both the
'doc' checks and the 'test' checks. This allows the caller to run the
tests they care about with fewer invocations of `ci`.
As of this PR, automated testing will remain unchanged.
---
## Changelog
- tools/ci/src/main.rs refactored into staging and execution steps,
since the previous control flow did not naturally support continuing
after failure.
- Added "--keep-going" flag to `ci`.
- Added support for invoking `ci` with multiple arguments.
---
## Discussion
### Design considerations
I had originally split this into separate flags that controlled:
1. whether `--keep-going`/`--no-fail-fast` would be passed to the
constituent commands
2. whether `ci` would continue after a component test failed
However, I decided to merge these two behaviors, since I think that, if
you're in the business of seeing all the errors, you'll probably want to
actually see all of the errors. One slightly annoying thing, however,
about the new behavior with `--keep-going`, is that you will sometimes
find yourself wishing that the script would pause or something, since it
tends to fill the screen with a lot of junk. I have found that sending
stdout to /dev/null helps quite a bit, but I don't think `cargo fmt` or
`cargo clippy` actually write to stderr, so you need to be cognizant of
that (and perhaps invoke the lints separately).
~~Next, I'll mention that I feel somewhat strongly that the current
behavior of `ci` for automated testing should remain the same, since its
job is more like detecting that errors exist rather than finding all of
them.~~ (I was convinced this could have value.) Orthogonally, there is
the question of whether or not we might want to make this (or something
similar) actually the default behavior and make the automated test
script invoke some optional flags — it doesn't have to type with its
hands, after all. I'm not against that, but I don't really want to rock
the boat much more with this PR, since anyone who looks at the diff
might already be a little incensed.
Follow up to #11057
Implemented suggestions from reviewers from: a simpler
fit_canvas_to_parent leads to an explicit CSS setting to the canvas.
From my understanding, it has do be set after wgpu creation due to wgpu
overriding the canvas width/height:
4400a58470/examples/src/utils.rs (L68-L74)
# Changelog
- Re-enable a `fit_canvas_to_parent`, it's removal from
https://github.com/bevyengine/bevy/pull/11057 was problematic. Still,
its inner working is more simple than before: bevy doesn't handle its
resizing, winit does.
## Migration Guide
- Cancels the migration from
https://github.com/bevyengine/bevy/pull/11057
# Objective
This PR unpins `web-sys` so that unrelated projects that have
`bevy_render` in their workspace can finally update their `web-sys`.
More details in and fixes#12246.
## Solution
* Update `wgpu` from 0.19.1 to 0.19.3.
* Remove the `web-sys` pin.
* Update docs and wasm helper to remove the now-stale
`--cfg=web_sys_unstable_apis` Rust flag.
---
## Changelog
Updated `wgpu` to v0.19.3 and removed `web-sys` pin.
# Objective
Getting this error running ci locally.
```
$ cargo check -Zcheck-cfg --workspace
error: the `-Z` flag is only accepted on the nightly channel of Cargo, but this is the `stable` channel
See https://doc.rust-lang.org/book/appendix-07-nightly-rust.html for more information about Rust release channels.
thread 'main' panicked at tools\ci\src\main.rs:166:14:
Please fix failing cfg checks in output above.: command exited with non-zero code `cargo check -Zcheck-cfg --workspace`: 101
```
## Solution
- Add `+nightly` flag to the `check-cfg` pass.
---
Obviously we shouldn't be running `nightly` Cargo, but at least now
local running of `cargo run -p ci` will pass.
# Objective
Memory usage optimisation
## Solution
`HashMap` and `HashSet`'s keys are immutable. So using mutable types
like `String`, `Vec<T>`, or `PathBuf` as a key is a waste of memory:
they have an extra `usize` for their capacity and may have spare
capacity.
This PR replaces these types by their immutable equivalents `Box<str>`,
`Box<[T]>`, and `Box<Path>`.
For more context, I recommend watching the [Use Arc Instead of
Vec](https://www.youtube.com/watch?v=A4cKi7PTJSs) video.
---------
Co-authored-by: James Liu <contact@jamessliu.com>
