[FIX] fmt documenation issue

examples/scene/scene.rs

@@ -1,28 +1,28 @@
 //! # Introduction
 //!
-//! This example demonstrates how to load scene data from files and then dynamically 
-//! apply that data to entities in your Bevy `World`. This includes spawning new 
-//! entities and applying updates to existing ones. Scenes in Bevy encapsulate 
-//! serialized and deserialized `Components` or `Resources` so that you can easily 
+//! This example demonstrates how to load scene data from files and then dynamically
+//! apply that data to entities in your Bevy `World`. This includes spawning new
+//! entities and applying updates to existing ones. Scenes in Bevy encapsulate
+//! serialized and deserialized `Components` or `Resources` so that you can easily
 //! store, load, and manipulate data outside of a purely code-driven context.
 //!
 //! This example also shows how to do the following:
-//! * Register your custom types for reflection, which allows them to be serialized, 
+//! * Register your custom types for reflection, which allows them to be serialized,
 //!   deserialized, and manipulated dynamically.
-//! * Skip serialization of fields you don't want stored in your scene files (like 
+//! * Skip serialization of fields you don't want stored in your scene files (like
 //!   runtime values that should always be computed dynamically).
-//! * Save a new scene to disk to show how it can be updated compared to the original 
+//! * Save a new scene to disk to show how it can be updated compared to the original
 //!   scene file (and how that updated scene file might then be used later on).
 //!
-//! The example proceeds by creating components and resources, registering their types, 
-//! loading a scene from a file, logging when changes are detected, and finally saving 
-//! a new scene file to disk. This is useful for anyone wanting to see how to integrate 
+//! The example proceeds by creating components and resources, registering their types,
+//! loading a scene from a file, logging when changes are detected, and finally saving
+//! a new scene file to disk. This is useful for anyone wanting to see how to integrate
 //! file-based scene workflows into their Bevy projects.
 //!
 //! # Note on Filesystem
 //!
-//! The saving behavior uses the standard filesystem APIs, which are blocking, so it 
-//! utilizes a thread pool (`IoTaskPool`) to avoid stalling the main thread. This 
+//! The saving behavior uses the standard filesystem APIs, which are blocking, so it
+//! utilizes a thread pool (`IoTaskPool`) to avoid stalling the main thread. This
 //! won't work on WASM because WASM typically doesn't have direct filesystem access.
 //!
 
@@ -48,19 +48,19 @@ fn main() {
         .run();
 }
 
-//! # Components, Resources, and Reflection
-//!
-//! Below are some simple examples of how to define your own Bevy `Component` types
-//! and `Resource` types so that they can be properly reflected, serialized, and
-//! deserialized. The `#[derive(Reflect)]` macro enables Bevy's reflection features,
-//! and we add component-specific reflection by using `#[reflect(Component)]`. 
-//! We also illustrate how to skip serializing fields and how `FromWorld` can help
-//! create runtime-initialized data.
-
+/// # Components, Resources, and Reflection
+///
+/// Below are some simple examples of how to define your own Bevy `Component` types
+/// and `Resource` types so that they can be properly reflected, serialized, and
+/// deserialized. The `#[derive(Reflect)]` macro enables Bevy's reflection features,
+/// and we add component-specific reflection by using `#[reflect(Component)]`.
+/// We also illustrate how to skip serializing fields and how `FromWorld` can help
+/// create runtime-initialized data.
+///
 /// A sample component that is fully serializable.
 ///
-/// This component has public `x` and `y` fields that will be included in 
-/// the scene files. Notice how it derives `Default`, `Reflect`, and declares 
+/// This component has public `x` and `y` fields that will be included in
+/// the scene files. Notice how it derives `Default`, `Reflect`, and declares
 /// itself as a reflected component with `#[reflect(Component)]`.
 #[derive(Component, Reflect, Default)]
 #[reflect(Component)] // this tells the reflect derive to also reflect component behaviors
@@ -73,7 +73,7 @@ struct ComponentA {
 
 /// A sample component that includes both serializable and non-serializable fields.
 ///
-/// This is useful for skipping serialization of runtime data or fields you 
+/// This is useful for skipping serialization of runtime data or fields you
 /// don't want written to scene files.
 #[derive(Component, Reflect)]
 #[reflect(Component)]
@@ -85,8 +85,8 @@ struct ComponentB {
     pub _time_since_startup: Duration,
 }
 
-/// This implements `FromWorld` for `ComponentB`, letting us initialize runtime fields 
-/// by accessing the current ECS resources. In this case, we acquire the `Time` resource 
+/// This implements `FromWorld` for `ComponentB`, letting us initialize runtime fields
+/// by accessing the current ECS resources. In this case, we acquire the `Time` resource
 /// and store the current elapsed time.
 impl FromWorld for ComponentB {
     fn from_world(world: &mut World) -> Self {
@@ -108,11 +108,11 @@ struct ResourceA {
     pub score: u32,
 }
 
-//! # Scene File Paths
-//!
-//! `SCENE_FILE_PATH` points to the original scene file that we'll be loading. 
-//! `NEW_SCENE_FILE_PATH` points to the new scene file that we'll be creating 
-//! (and demonstrating how to serialize to disk).
+/// # Scene File Paths
+///
+/// `SCENE_FILE_PATH` points to the original scene file that we'll be loading.
+/// `NEW_SCENE_FILE_PATH` points to the new scene file that we'll be creating
+/// (and demonstrating how to serialize to disk).
 
 /// The initial scene file will be loaded below and not change when the scene is saved.
 const SCENE_FILE_PATH: &str = "scenes/load_scene_example.scn.ron";
@@ -122,9 +122,9 @@ const NEW_SCENE_FILE_PATH: &str = "scenes/load_scene_example-new.scn.ron";
 
 /// Loads a scene from an asset file and spawns it in the current world.
 ///
-/// Spawning a `DynamicSceneRoot` creates a new parent entity, which then spawns new 
-/// instances of the scene's entities as its children. If you modify the 
-/// `SCENE_FILE_PATH` scene file, or if you enable file watching, you can see 
+/// Spawning a `DynamicSceneRoot` creates a new parent entity, which then spawns new
+/// instances of the scene's entities as its children. If you modify the
+/// `SCENE_FILE_PATH` scene file, or if you enable file watching, you can see
 /// changes reflected immediately.
 fn load_scene_system(mut commands: Commands, asset_server: Res<AssetServer>) {
     commands.spawn(DynamicSceneRoot(asset_server.load(SCENE_FILE_PATH)));
@@ -133,7 +133,7 @@ fn load_scene_system(mut commands: Commands, asset_server: Res<AssetServer>) {
 /// Logs changes made to `ComponentA` entities, and also checks whether `ResourceA`
 /// has been recently added.
 ///
-/// Any time a `ComponentA` is modified, that change will appear here. This system 
+/// Any time a `ComponentA` is modified, that change will appear here. This system
 /// demonstrates how you might detect and handle scene updates at runtime.
 fn log_system(
     query: Query<(Entity, &ComponentA), Changed<ComponentA>>,
@@ -153,11 +153,11 @@ fn log_system(
     }
 }
 
-/// Demonstrates how to create a new scene from scratch, populate it with data, 
+/// Demonstrates how to create a new scene from scratch, populate it with data,
 /// and then serialize it to a file. The new file is written to `NEW_SCENE_FILE_PATH`.
 ///
-/// This system creates a fresh world, duplicates the type registry so that our 
-/// custom component types are recognized, spawns some sample entities and resources, 
+/// This system creates a fresh world, duplicates the type registry so that our
+/// custom component types are recognized, spawns some sample entities and resources,
 /// and then serializes the resulting dynamic scene.
 fn save_scene_system(world: &mut World) {
     // Scenes can be created from any ECS World.