Merge main and fix conflicts #5
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Bumps [crate-ci/typos](https://github.com/crate-ci/typos) from 1.20.10 to 1.21.0. <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.21.0</h2> <h2>[1.21.0] - 2024-04-30</h2> <h3>Fixes</h3> <ul> <li>Updated the dictionary with the <a href="https://redirect.github.com/crate-ci/typos/issues/956">April 2024</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.21.0] - 2024-04-30</h2> <h3>Fixes</h3> <ul> <li>Updated the dictionary with the <a href="https://redirect.github.com/crate-ci/typos/issues/956">April 2024</a> changes</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/crate-ci/typos/commit/d503507db9c5d116c79135435b149cd0f27d726e"><code>d503507</code></a> chore: Release</li> <li><a href="https://github.com/crate-ci/typos/commit/b57a417c998df6562d5cd8772d9400bbe4c66664"><code>b57a417</code></a> chore: Release</li> <li><a href="https://github.com/crate-ci/typos/commit/82a3621e9042e3d9b76bf722befef4a283ac5190"><code>82a3621</code></a> chore(ci): Fix a bad merge</li> <li><a href="https://github.com/crate-ci/typos/commit/0fef712c2a4f1f8a0a0e950fd28eb7a587c053e2"><code>0fef712</code></a> docs: Update changelog</li> <li><a href="https://github.com/crate-ci/typos/commit/5aeb9bf91437b5abdb9a8710e4e4aaca56ab9722"><code>5aeb9bf</code></a> Merge pull request <a href="https://redirect.github.com/crate-ci/typos/issues/1008">#1008</a> from epage/april</li> <li><a href="https://github.com/crate-ci/typos/commit/3f19efbe830a84f24af76b97ac8e211a7f6f022f"><code>3f19efb</code></a> chore(deps): Update Rust Stable to v1.77 (<a href="https://redirect.github.com/crate-ci/typos/issues/1006">#1006</a>)</li> <li><a href="https://github.com/crate-ci/typos/commit/7d6e6a1c37df1407a8c639909478a6ef61371633"><code>7d6e6a1</code></a> fix(dict): April updates</li> <li><a href="https://github.com/crate-ci/typos/commit/919912762c3c3511cdc6544ef2e34267cfec2ed8"><code>9199127</code></a> Merge pull request <a href="https://redirect.github.com/crate-ci/typos/issues/1005">#1005</a> from epage/template</li> <li><a href="https://github.com/crate-ci/typos/commit/b6c895ea49148b4f79402069661e6367c2cbec70"><code>b6c895e</code></a> chore: Update from _rust/main template</li> <li><a href="https://github.com/crate-ci/typos/commit/51de731521efb05c5503e05c33036d8fa439bc5a"><code>51de731</code></a> chore(ci): Lint clippy::items_after_statements seems too strict</li> <li>Additional commits viewable in <a href="https://github.com/crate-ci/typos/compare/v1.20.10...v1.21.0">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…e#13251) Fixes a regression introduced by bevyengine#13031.
# Objective Fixes bevyengine#12966 ## Solution Renaming multi_threaded feature to match snake case ## Migration Guide Bevy feature multi-threaded should be refered to multi_threaded from now on.
) Switched the return type from `Vec3` to `Dir3` for directional axis methods within the `GlobalTransform` component. ## Migration Guide The `GlobalTransform` component's directional axis methods (e.g., `right()`, `left()`, `up()`, `down()`, `back()`, `forward()`) have been updated from returning `Vec3` to `Dir3`.
# Objective Since `align` was introduced, it has been reworked to allow the input of `Dir3` instead of `Vec3`, and we also introduced random sampling for points on a sphere and then for `Dir3`. Previously, this example rolled its own random generation, but it doesn't need to any more. ## Solution Refactor the 'align' example to use `Dir3` instead of `Vec3`, using the `bevy_math` API for random directions.
# Objective I'm adopting bevyengine#9122 and pulling some of the non controversial changes out to make the final pr easier to review. This pr removes the NonSend resource usage from `bevy_log`. ## Solution `tracing-chrome` uses a guard that is stored in the world, so that when it is dropped the json log file is written out. The guard is Send + !Sync, so we can store it in a SyncCell to hold it in a regular resource instead of using a non send resource. ## Testing Tested by running an example with `-F tracing chrome` and making sure there weren't any errors and the json file was created. --- ## Changelog - replaced `bevy_log`'s usage of a non send resource.
# Objective - Add some useful methods to `Ellipse` ## Solution - Added `Ellipse::perimeter()` and `::focal_length()` --------- Co-authored-by: IQuick 143 <IQuick143cz@gmail.com>
# Objective fixes clippy warning related to using a std::f32::EPSILON which is planned to be depreciated for f32::EPSILON
Copied almost verbatim from the volumetric fog PR # Objective - Managing mesh view layouts is complicated ## Solution - Extract it to it's own struct - This was done as part of bevyengine#13057 and is copied almost verbatim. I wanted to keep this part of the PR it's own atomic commit in case we ever have to revert fog or run a bisect. This change is good whether or not we have volumetric fog. Co-Authored-By: @pcwalton
# 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`](https://github.com/bevyengine/bevy/tree/4f9f987099224ca41aab91a582b80fca8eb969f8/crates/bevy_ecs/macros). - The one crate that does not follow this convention is [`bevy_reflect_derive`](https://github.com/bevyengine/bevy/tree/4f9f987099224ca41aab91a582b80fca8eb969f8/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 - Adds a basic `Extrusion<T: Primitive2d>` shape, suggestion of bevyengine#10572 ## Solution - Adds `Measured2d` and `Measured3d` traits for getting the perimeter/area or area/volume of shapes. This allows implementing `.volume()` and `.area()` for all extrusions `Extrusion<T: Primitive2d + Measured2d>` within `bevy_math` - All existing perimeter, area and volume implementations for primitves have been moved into implementations of `Measured2d` and `Measured3d` - Shapes should be extruded along the Z-axis since an extrusion of depth `0.` should be equivalent in everything but name to the base shape ## Caviats - I am not sure about the naming. `Extrusion<T>` could also be `Prism<T>` and the `MeasuredNd` could also be something like `MeasuredPrimitiveNd`. If you have any other suggestions, please fell free to share them :) ## Future work This PR adds a basic `Extrusion` shape and does not implement a lot of things you might want it to. Some of the future possibilities include: - [ ] bounding for extrusions - [ ] making extrusions work with gizmos - [ ] meshing --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective There's a TODO comment above the `AssetMetaCheck` enum mentioning this should have been done in 0.13 ## Solution Do it in 0.14 ## Testing I've checked that all the asset tests compile. I've also run the asset_processing and asset_settings tests and they both work. --- ## Changelog ### Changed - [`AssetMetaCheck`](https://docs.rs/bevy/latest/bevy/asset/enum.AssetMetaCheck.html) is no longer a resource and is now a field on the [`AssetPlugin`](https://docs.rs/bevy/latest/bevy/asset/struct.AssetPlugin.html). ## Migration Guide Changes to how bevy handles asset meta files now need to be specified when inserting the `AssetPlugin`.
…ed length. (bevyengine#13210) WebGL 2 doesn't support variable-length uniform buffer arrays. So we arbitrarily set the length of the visibility ranges field to 64 on that platform. --------- Co-authored-by: IceSentry <c.giguere42@gmail.com>
# Objective Currently, the 2d pipeline only has a transparent pass that is used for everything. I want to have separate passes for opaque/alpha mask/transparent meshes just like in 3d. This PR does the basic work to start adding new phases to the 2d pipeline and get the current setup a bit closer to 3d. ## Solution - Use `ViewNode` for `MainTransparentPass2dNode` - Added `Node2d::StartMainPass`, `Node2d::EndMainPass` - Rename everything to clarify that the main pass is currently the transparent pass --- ## Changelog - Added `Node2d::StartMainPass`, `Node2d::EndMainPass` ## Migration Guide If you were using `Node2d::MainPass` to order your own custom render node. You now need to order it relative to `Node2d::StartMainPass` or `Node2d::EndMainPass`.
# Objective - Some developers enable Github Actions for their fork and commit directly to main. This triggers the `docs.yml` action, which attempts to deploy the documentation even if Github Pages is not enabled. (It also creates a `CNAME` file specific to Bevy and should not be used in forks, even for testing.) - For an example, see [this run](https://github.com/tychedelia/bevy/actions/runs/8978912060/job/24660082729). ## Solution - Only attempt to deploy docs when running from the main Bevy repository. - This does not affect us checking `cargo doc` on pull requests, since that it done in `ci.yml`. ## Testing It's difficult to test this, but you'd probably: 1. Fork Bevy 2. Cherry pick this PR's commits onto the main branch of your fork. 3. Push another commit to the main branch, triggering Github Actions. 4. Check the Github Actions job summary to ensure that the `build-and-deploy` job is skipped.
# Objective Finish the `try_apply` implementation started in bevyengine#6770 by @feyokorenhof. Supersedes and closes bevyengine#6770. Closes bevyengine#6182 ## Solution Add `try_apply` to `Reflect` and implement it in all the places that implement `Reflect`. --- ## Changelog Added `try_apply` to `Reflect`. --------- Co-authored-by: Feyo Korenhof <feyokorenhof@gmail.com> Co-authored-by: Gino Valente <49806985+MrGVSV@users.noreply.github.com>
# Objective Fixes bevyengine#11457. Fixes bevyengine#22. ## Solution Based on [another headless application](https://github.com/richardanaya/headless/) --- ## Changelog - Adopted to bevy 0.14 --------- Co-authored-by: BD103 <59022059+BD103@users.noreply.github.com> Co-authored-by: François Mockers <francois.mockers@vleue.com>
# Objective fixes bevyengine#13224 adds conversions for Vec3 and Vec4 since these appear so often ## Solution added Covert trait (couldn't think of good name) for [f32; 4], [f32, 3], Vec4, and Vec3 along with the symmetric implementation ## Changelog added conversions between arrays and vector to colors and vice versa #migration LinearRgba appears to have already had implicit conversions for [f32;4] and Vec4
# 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 Unblocks bevyengine#11659. Currently the `Reflect` derive macro has to go through a merge process for each `#[reflect]`/`#[reflet_value]` attribute encountered on a container type. Not only is this a bit inefficient, but it also has a soft requirement that we can compare attributes such that an error can be thrown on duplicates, invalid states, etc. While working on bevyengine#11659 this proved to be challenging due to the fact that `syn` types don't implement `PartialEq` or `Hash` without enabling the `extra-traits` feature. Ideally, we wouldn't have to enable another feature just to accommodate this one use case. ## Solution Removed `ContainerAttributes::merge`. This was a fairly simple change as we could just have the parsing functions take `&mut self` instead of returning `Self`. ## Testing CI should build as there should be no user-facing change.
# Objective Sometimes it's nice to iterate over all the coordinate axes using something like `Vec3::AXES`. This was not available for the corresponding `Dir` types and now it is. ## Solution We already have things like `Dir2::X`, `Dir3::Z` and so on, so I just threw them in an array like the vector types do it. I also slightly refactored the sphere gizmo code to use `Dir3::AXES` and operate on directions instead of using `Dir3::new_unchecked`. ## Testing I looked at the sphere in the `3d_gizmos` example and it seems to work, so I assume I didn't break anything.
# Objective I am emboldened by my last small PR and am here with another. - **Describe the objective or issue this PR addresses.** It would be nice if `FrameCount` could be used by downstream plugins that want to use frame data. The example that I have in mind is [`leafwing_input_playback`](Leafwing-Studios/leafwing_input_playback#29) which has a [duplicate implementation of `FrameCount`](https://github.com/Leafwing-Studios/leafwing_input_playback/blob/main/src/frame_counting.rs#L9-L37) used in several structs which rely on those derives (or otherwise the higher-level structs would have to implement these traits manually). That crate, using `FrameCount`, tracks input frames and timestamps and enables various playback modes. I am aware that bevy org refrains from deriving lots of unnecessary stuff on bevy types to avoid compile time creep. It is worth mentioning the (equally reasonable) alternative that downstream crates _should_ implement some `FrameCount` themselves if they want special behavior from it. ## Solution - **Describe the solution used to achieve the objective above.** I added derives for `PartialEq, Eq, PartialOrd, Ord` and implementations for `serde::{Deserialize, Serialize}` to `FrameCount`. ## Testing Manually confirmed that the serde implementation works, but that's all. Let me know if I should do more here. --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective - Fixes bevyengine#12543 ## Solution - Removed `ClampColor` ## Testing - CI Passed --- ## Migration Guide Manually clamp the various colour components yourself if this behaviour is still required. ```rust fn clamped_srgba(color: Srgba) -> Srgba { Srgba { red: color.red.clamp(0., 1.), green: color.green.clamp(0., 1.), blue: color.blue.clamp(0., 1.), alpha: color.alpha.clamp(0., 1.), } } ```
…#13326) # Objective - Example `render_primitives` is painful to look at for the plane in 3d, the gizmo seems to have extra rotations https://github.com/bevyengine/bevy/assets/8672791/08509624-14ac-4f00-a758-9a14233ef1a9 ## Solution - Take the normal of the normal before rotation, then rotate it ## Testing - Run the example, rotations are more in sync https://github.com/bevyengine/bevy/assets/8672791/91c26ce4-4b7b-4575-ba32-7c32026e4596
…3271) # Objective Fixes bevyengine#13230 ## Solution Uses solution described in bevyengine#13230 They mention a worry about adding a branch, but I'm not sure there is one. This code ```Rust #[no_mangle] pub fn next_if_some(num: i32, b: Option<bool>) -> i32 { num + b.is_some() as i32 } ``` produces this assembly with opt-level 3 ```asm next_if_some: xor eax, eax cmp sil, 2 setne al add eax, edi ret ``` ## Testing Added test from bevyengine#13230, tagged it as ignore as it is only useful in release mode and very slow if you accidentally invoke it in debug mode. --- ## Changelog Iterationg of ListIter will no longer overflow and wrap around ## Migration Guide
# Objective Fixes two issues related to bevyengine#13208. First, we ensure render resources for a window are always dropped first to ensure that the `winit::Window` always drops on the main thread when it is removed from `WinitWindows`. Previously, changes in bevyengine#12978 caused the window to drop in the render world, causing issues. We accomplish this by delaying despawning the window by a frame by inserting a marker component `ClosingWindow` that indicates the window has been requested to close and is in the process of closing. The render world now responds to the equivalent `WindowClosing` event rather than `WindowCloseed` which now fires after the render resources are guarunteed to be cleaned up. Secondly, fixing the above caused (revealed?) that additional events were being delivered to the the event loop handler after exit had already been requested: in my testing `RedrawRequested` and `LoopExiting`. This caused errors to be reported try to send an exit event on the close channel. There are two options here: - Guard the handler so no additional events are delivered once the app is exiting. I ~considered this but worried it might be confusing or bug prone if in the future someone wants to handle `LoopExiting` or some other event to clean-up while exiting.~ We are now taking this approach. - Only send an exit signal if we are not already exiting. ~It doesn't appear to cause any problems to handle the extra events so this seems safer.~ Fixing this also appears to have fixed bevyengine#13231. Fixes bevyengine#10260. ## Testing Tested on mac only. --- ## Changelog ### Added - A `WindowClosing` event has been added that indicates the window will be despawned on the next frame. ### Changed - Windows now close a frame after their exit has been requested. ## Migration Guide - Ensure custom exit logic does not rely on the app exiting the same frame as a window is closed.
|
I implemented this, thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Merged main and fix the conficts related to view_layouts. I also remove some unnecessary usage of .view_layouts