Merge branch 'main' into 396_add_accesibility_lints_to_ci

Author: TrialDragon

.github/workflows/ci.yml

@@ -107,6 +107,22 @@ jobs:
           npx wait-on http://127.0.0.1:1111
           npx pa11y-ci --sitemap http://127.0.0.1:1111/sitemap.xml
 
+  typos:
+    runs-on: ubuntu-latest
+    timeout-minutes: 30
+    steps:
+      - uses: actions/checkout@v4
+      - name: Check for typos
+        uses: crate-ci/[email protected]
+      - name: Typos info
+        if: failure()
+        run: |
+          echo 'To fix typos, please run `typos -w`'
+          echo 'To check for a diff, run `typos`'
+          echo 'You can find typos here: https://crates.io/crates/typos'
+          echo 'if you use VSCode, you can also install `Typos Spell Checker'
+          echo 'You can find the extension here: https://marketplace.visualstudio.com/items?itemName=tekumara.typos-vscode'
+
   generate-assets:
     needs: [super-linter, test-code-examples, lint-tools, check-hide-lines]
     runs-on: ubuntu-latest

code-validation/src/lib.rs

@@ -1,6 +1,6 @@
 //! This crate is used to validate the rust code of the `bevy` website.
 //!
-//! It is currently used to validate the rust code of the offical `bevy` book.
+//! It is currently used to validate the rust code of the official `bevy` book.
 //! The modules represents the folder structure of the website.
 
 mod learn {

content/learn/book/ecs/entities-components.md

@@ -7,7 +7,7 @@ status = 'hidden'
 +++
 
 **Entities** are the fundamental objects of your game world, whizzing around, storing cameras, being controlled by the player or tracking the state of a button.
-On its own, the [`Entity`] type is a simple identifer: it has neither behavior nor data.
+On its own, the [`Entity`] type is a simple identifier: it has neither behavior nor data.
 Components store this data, and define the overlapping categories that the entity belongs to.
 
 Informally, we use the term "entity" to refer to the conceptual entry in our [`World`]: all of the component data with the correct identifier, although it's very rare to use all of the data for a single entity at once.
@@ -44,7 +44,7 @@ fn spawning_system(mut commands: Commands){
 ## Working With Components
 
 Spawning an entity doesn't add any behavior or create a "physical object" in our game like it might in other engines.
-Instead, all it does is provide us an [`Entity`] identifer for a collection of component data.
+Instead, all it does is provide us an [`Entity`] identifier for a collection of component data.
 
 In order to make this useful, we need to be able to add, remove and modify component data for each entity.
 
@@ -354,7 +354,7 @@ Over time, the Bevy community has converged on a few standard pieces of advice f
   - not as useful as you might hope for upholding invariants; components will be able to be accidentally modified independently later
 - use [struct update syntax] to modify component bundles
   - [`..default()`] is a particularly common idiom, to modify a struct from its default values
-- consider definining traits for related components
+- consider defining traits for related components
   - this allows you to ensure a consistent interface
   - this can be very powerful in combination with generic systems that use trait bounds
 

content/learn/migration-guides/0.10-to-0.11.md

@@ -725,7 +725,7 @@ use bevy::ecs::reflect::AppTypeRegistry
     <div class="migration-guide-area-tag">Scenes</div>
 </div>
 
-In `bevy_ecs`, `ReflectMapEntities::map_entites` now requires an additional `entities` parameter to specify which entities it applies to. To keep the old behavior, use the new `ReflectMapEntities::map_all_entities`, but consider if passing the entities in specifically might be better for your use case to avoid bugs.
+In `bevy_ecs`, `ReflectMapEntities::map_entities` now requires an additional `entities` parameter to specify which entities it applies to. To keep the old behavior, use the new `ReflectMapEntities::map_all_entities`, but consider if passing the entities in specifically might be better for your use case to avoid bugs.
 
 ### [Require `#[derive(Event)]` on all Events](https://github.com/bevyengine/bevy/pull/7086)
 

content/learn/migration-guides/0.11-to-0.12.md

@@ -1550,3 +1550,23 @@ App::new()
 ```
 
 </div>
+
+### [View Transformations](https://github.com/bevyengine/bevy/pull/9726)
+
+`mesh_functions::mesh_position_world_to_clip` was moved and renamed to `view_transformations::position_world_to_clip`. It now also takes a `vec3` instead of a `vec4` so you will need to use `vec4.xyz` to get a `vec3`.
+
+```rust
+// 0.11
+#import bevy_pbr::mesh_functions::mesh_position_world_to_clip
+fn mesh_position_local_to_clip(model: mat4x4<f32>, vertex_position: vec4<f32>) -> vec4<f32> {
+    let world_position = mesh_position_local_to_world(model, vertex_position);
+    return mesh_position_world_to_clip(world_position);
+}
+
+// 0.12
+#import bevy_pbr::view_transformations::position_world_to_clip;
+fn mesh_position_local_to_clip(model: mat4x4<f32>, vertex_position: vec4<f32>) -> vec4<f32> {
+    let world_position = mesh_position_local_to_world(model, vertex_position);
+    return position_world_to_clip(world_position.xyz);
+}
+```

content/learn/migration-guides/0.12-to-0.13.md

@@ -62,7 +62,7 @@ The `ReadAssetBytesError::Io` variant now contains two named fields instead of c
     <div class="migration-guide-area-tag">Assets</div>
 </div>
 
-If you relied on any of the panicing `From<Untyped...>` implementations, simply call the existing `typed` methods instead. Alternatively, use the new `TryFrom` implementation instead to directly expose possible mistakes.
+If you relied on any of the panicking `From<Untyped...>` implementations, simply call the existing `typed` methods instead. Alternatively, use the new `TryFrom` implementation instead to directly expose possible mistakes.
 
 ### [Use `impl Into<A>` for `Assets::add`](https://github.com/bevyengine/bevy/pull/10878)
 
@@ -577,7 +577,7 @@ Calls to `fn map_entities(&mut self, entity_mapper: &mut EntityMapper)` need to
 The `PipelinedRendering` plugin is no longer exported on wasm. If you are including it in your wasm builds you should remove it.
 
 ```rust
-#[cfg(all(not(target_arch = "wasm32"))]
+#[cfg(not(target_arch = "wasm32"))]
 app.add_plugins(bevy_render::pipelined_rendering::PipelinedRenderingPlugin);
 ```
 
@@ -1115,11 +1115,11 @@ pub struct MyDynamicLabel(&'static str);
 #### Nodes
 
 - `bevy_core_pipeline::core_2d::graph`:
-  - `node::MSAA_WRITEBACK -> Node2d::MsaaWriteback` `node::MAIN_PASS ->Node2d::MainPass` `node::BLOOM -> Node2d::Bloom` `node::TONEMAPPING -> Node2d::Tonemapping` `node::FXAA -> Node2d::Fxaa` `node::UPSCALING -> Node2d::Upscaling` `node::CONTRAST_ADAPTIVE_SHARPENING -> Node2d::ConstrastAdaptiveSharpening` `node::END_MAIN_PASS_POST_PROCESSING -> Node2d::EndMainPassPostProcessing`
+  - `node::MSAA_WRITEBACK -> Node2d::MsaaWriteback` `node::MAIN_PASS ->Node2d::MainPass` `node::BLOOM -> Node2d::Bloom` `node::TONEMAPPING -> Node2d::Tonemapping` `node::FXAA -> Node2d::Fxaa` `node::UPSCALING -> Node2d::Upscaling` `node::CONTRAST_ADAPTIVE_SHARPENING -> Node2d::ContrastAdaptiveSharpening` `node::END_MAIN_PASS_POST_PROCESSING -> Node2d::EndMainPassPostProcessing`
 - `bevy_core_pipeline::core_3d::graph`:
   - `node::MSAA_WRITEBACK -> Node3d::MsaaWriteback` `node::PREPASS -> Node3d::Prepass` `node::DEFERRED_PREPASS -> Node3d::DeferredPrepass` `node::COPY_DEFERRED_LIGHTING_ID -> Node3d::CopyDeferredLightingId` `node::END_PREPASSES -> Node3d::EndPrepasses` `node::START_MAIN_PASS -> Node3d::StartMainPass` `node::MAIN_OPAQUE_PASS -> Node3d::MainOpaquePass` `node::MAIN_TRANSMISSIVE_PASS -> Node3d::MainTransmissivePass` `node::MAIN_TRANSPARENT_PASS -> Node3d::MainTransparentPass` `node::END_MAIN_PASS -> Node3d::EndMainPass` `node::BLOOM -> Node3d::Bloom` `node::TONEMAPPING -> Node3d::Tonemapping` `node::FXAA -> Node3d::Fxaa` `node::UPSCALING -> Node3d::Upscaling` `node::CONTRAST_ADAPTIVE_SHARPENING -> Node3d::ContrastAdaptiveSharpening` `node::END_MAIN_PASS_POST_PROCESSING -> Node3d::EndMainPassPostProcessing`
 - `bevy_core_pipeline`: `taa::draw_3d_graph::node::TAA -> Node3d::Taa`
-- `bevy_pbr`: `draw_3d_graph::node::SHADOW_PASS -> NodePbr::ShadowPass` `ssao::draw_3d_graph::node::SCREEN_SPACE_AMBIENT_OCCLUSION -> NodePbr::ScreenSpaceAmbientOcclusion` `deferred::DEFFERED_LIGHTING_PASS -> NodePbr::DeferredLightingPass`
+- `bevy_pbr`: `draw_3d_graph::node::SHADOW_PASS -> NodePbr::ShadowPass` `ssao::draw_3d_graph::node::SCREEN_SPACE_AMBIENT_OCCLUSION -> NodePbr::ScreenSpaceAmbientOcclusion` `deferred::DEFERRED_LIGHTING_PASS -> NodePbr::DeferredLightingPass`
 - `bevy_render`: `main_graph::node::CAMERA_DRIVER -> graph::CameraDriverLabel`
 - `bevy_ui::render`: `draw_ui_graph::node::UI_PASS -> graph::Nodeui::UiPass`
 
@@ -1386,7 +1386,7 @@ Callers of `Transform::up()` and similar functions may have to dereference the r
 
 The clipped areas of UI nodes are no longer interactive.
 
-`RelativeCursorPostion` is now calculated relative to the whole node’s position and size, not only the visible part. Its `mouse_over` method only returns true when the cursor is over an unclipped part of the node.
+`RelativeCursorPosition` is now calculated relative to the whole node’s position and size, not only the visible part. Its `mouse_over` method only returns true when the cursor is over an unclipped part of the node.
 
 `RelativeCursorPosition` no longer implements `Deref` and `DerefMut`.
 
@@ -1450,6 +1450,19 @@ Common examples of the updated variants are as follows:
 
 See the relevant [documentation](https://docs.rs/bevy/0.13.0/bevy/input/keyboard/enum.KeyCode.html) for more information.
 
+#### ReceivedCharacter changes
+
+The `char` field of [`ReceivedCharacter`] is now a [`SmolStr`], and _could_ contain multiple characters. See these [winit docs] for details.
+
+A simple workaround if you need a `char` is to call `.chars().last()`.
+
+It's now possible to use [`KeyEvent::logical_key`]'s `Character` variant instead if you need consistent cross-platform behavior and/or a unified event stream with non-character events.
+
+[winit docs]: https://docs.rs/winit/0.29.10/winit/event/struct.KeyEvent.html#structfield.text
+[`SmolStr`]: https://docs.rs/smol_str/0.2.1/smol_str/struct.SmolStr.html
+[`ReceivedCharacter`]: https://docs.rs/bevy/latest/bevy/prelude/struct.ReceivedCharacter.html
+[`KeyEvent::logical_key`]: https://docs.rs/bevy/latest/bevy/input/keyboard/struct.KeyboardInput.html#structfield.logical_key
+
 ### [Remove CanvasParentResizePlugin](https://github.com/bevyengine/bevy/pull/11057)
 
 <div class="migration-guide-area-tags">
@@ -1488,14 +1501,6 @@ Consider changing usage:
 
 `Window` has a new [`name`](https://docs.rs/bevy/latest/bevy/prelude/struct.Window.html#structfield.name) field for specifying the "window class name." If you don't need this, set it to `None`.
 
-### [ReceivedCharacter.char is now SmolStr instead of char]
-
-<div class="migration-guide-area-tags">
-    <div class="migration-guide-area-tag">Windowing</div>
-</div>
-
-To restore the previous behavior, use `.chars().nth(0)`
-
 ### [delete methods deprecated in 0.12](https://github.com/bevyengine/bevy/pull/10693)
 
 <div class="migration-guide-area-tags">

content/learn/migration-guides/0.4-to-0.5.md

@@ -247,7 +247,7 @@ It is still possible to register the driver manually using
 
 ## ChangedRes removed
 
-This change was made to allow for more flexiblity and more consistent behavior with change detection for components.
+This change was made to allow for more flexibility and more consistent behavior with change detection for components.
 
 ```rust
 // 0.4

content/learn/migration-guides/0.5-to-0.6.md

@@ -69,7 +69,7 @@ impl Plugin for SomePlugin {
 ### The "Component" trait now needs to be derived
 
 Bevy no longer has a blanket implementation for the [`Component`] trait.
-Instead you need to derive (or manualy implement) the trait for every Type that needs it.
+Instead you need to derive (or manually implement) the trait for every Type that needs it.
 
 ```rust
 // 0.5

content/learn/migration-guides/0.7-to-0.8.md

@@ -72,11 +72,11 @@ camera.world_to_viewport(transform, world_position);
 
 ### [Visibilty Inheritance, universal ComputedVisibility and RenderLayers support](https://github.com/bevyengine/bevy/pull/5310)
 
-[`Visibility`] is now propagated into children in a similar way to `Transform`. Root elements of a hierarchy must now contain [`Visibility`] and [`ComputedVisiblity`] for visibility propagation to work.
+[`Visibility`] is now propagated into children in a similar way to `Transform`. Root elements of a hierarchy must now contain [`Visibility`] and [`ComputedVisibility`] for visibility propagation to work.
 
 [`SpatialBundle`] and [`VisibilityBundle`] have been added for convenience. If you were using a `TransformBundle` you should probably be using a [`SpatialBundle`] now.
 
-If you were previously reading `Visibility::is_visible` as the "actual visibility" for sprites or lights, use `ComputedVisibilty::is_visible()` instead:
+If you were previously reading `Visibility::is_visible` as the "actual visibility" for sprites or lights, use `ComputedVisibility::is_visible()` instead:
 
 ```rust
 // 0.7
@@ -99,7 +99,7 @@ fn system(query: Query<&ComputedVisibility>) {
 ```
 
 [`Visibility`]: https://docs.rs/bevy/0.8.0/bevy/render/view/struct.Visibility.html
-[`ComputedVisiblity`]: https://docs.rs/bevy/0.8.0/bevy/render/view/struct.ComputedVisibility.html
+[`ComputedVisibility`]: https://docs.rs/bevy/0.8.0/bevy/render/view/struct.ComputedVisibility.html
 [`SpatialBundle`]: https://docs.rs/bevy/0.8.0/bevy/prelude/struct.SpatialBundle.html
 [`VisibilityBundle`]: https://docs.rs/bevy/0.8.0/bevy/prelude/struct.VisibilityBundle.html
 

content/learn/migration-guides/0.9-to-0.10.md

@@ -103,7 +103,7 @@ app.configure_sets(
 #### Label types
 
 System labels have been renamed to systems sets and unified with stage labels.
-The `StageLabel` trait should be replaced by a system set, using the `SystemSet` trait as dicussed immediately below.
+The `StageLabel` trait should be replaced by a system set, using the `SystemSet` trait as discussed immediately below.
 
 Before: