trimmed white space

.github/ISSUE_TEMPLATE/bug_report.md

@@ -13,9 +13,9 @@ A clear and concise description of what the bug is.
 
 ## Meta
 
-Rust version: 
-Specs version / commit: 
-Operating system: 
+Rust version:
+Specs version / commit:
+Operating system:
 
 ## Reproduction
 

.travis.yml

@@ -61,7 +61,7 @@ after_success: |
   make install DESTDIR=../../kcov-build &&
   cd ../.. &&
   rm -rf kcov-master &&
-  for file in target/debug/specs-*; do 
+  for file in target/debug/specs-*; do
     [ -x "${file}" ] || continue;
     mkdir -p "target/cov/$(basename $file)";
     ./kcov-build/usr/local/bin/kcov --exclude-pattern=/.cargo,/usr/lib --verify "target/cov/$(basename $file)" "$file";

CHANGELOG.md

@@ -20,7 +20,7 @@
 * Remove `fnv` in favour of `hashbrown` ([#606])
 * Reexport `hibitset`, `rayon`, `shred` and `shrev` ([#606])
 * Reexport `shred_derive::SystemData` when `shred-derive` feature is enabled ([#606])
-* Reexport `specs_derive::{Component, ConvertSaveload}` when `specs-derive` feature is enabled 
+* Reexport `specs_derive::{Component, ConvertSaveload}` when `specs-derive` feature is enabled
 ([#606])
 
 [#542]: https://github.com/slide-rs/specs/pull/542

docs/tutorials/src/04_resources.md

@@ -68,31 +68,31 @@ impl<'a> System<'a> for UpdatePos {
 
 Note that all resources that a system accesses must be registered with
 `world.insert(resource)` before that system is run, or you will get a
-panic. If the resource has a `Default` implementation, this step is usually 
+panic. If the resource has a `Default` implementation, this step is usually
 done during `setup`, but again we will come back to this in a later chapter.
 
 For more information on `SystemData`, see [the system data chapter][cs].
 
 ## `Default` for resources
 
-As we have learned in previous chapters, to fetch a `Resource` in our 
-`SystemData`, we use `Read` or `Write`. However, there is one issue we 
+As we have learned in previous chapters, to fetch a `Resource` in our
+`SystemData`, we use `Read` or `Write`. However, there is one issue we
 have not mentioned yet, and that is the fact that `Read` and `Write` require
-`Default` to be implemented on the resource. This is because Specs will 
-automatically try to add a `Default` version of a resource to the `World` 
+`Default` to be implemented on the resource. This is because Specs will
+automatically try to add a `Default` version of a resource to the `World`
 during `setup` (we will come back to the `setup` stage in the next chapter).
 But how do we handle the case when we can't implement `Default` for our resource?
 
 There are actually three ways of doing this:
 
 * Using a custom `SetupHandler` implementation, you can provide this in `SystemData`
   with `Read<'a, Resource, TheSetupHandlerType>`.
-* By replacing `Read` and `Write` with `ReadExpect` and `WriteExpect`, which will 
+* By replacing `Read` and `Write` with `ReadExpect` and `WriteExpect`, which will
   cause the first dispatch of the `System` to panic unless the resource has been
   added manually to `World` first.
 * By using `Option<Read<'a, Resource>>`, if the resource really is optional. Note
-  that the order here is important, using `Read<'a, Option<Resource>>` will not 
-  result in the same behavior (it will try to fetch `Option<Resource>` from `World`, 
+  that the order here is important, using `Read<'a, Option<Resource>>` will not
+  result in the same behavior (it will try to fetch `Option<Resource>` from `World`,
   instead of doing an optional check if `Resource` exists).
 
 

docs/tutorials/src/06_system_data.md

@@ -11,7 +11,7 @@ struct Sys;
 
 impl<'a> System<'a> for Sys {
     type SystemData = (WriteStorage<'a, Pos>, ReadStorage<'a, Vel>);
-    
+
     fn run(&mut self, (pos, vel): Self::SystemData) {
         /* ... */
     }

docs/tutorials/src/08_join.md

@@ -45,7 +45,7 @@ use the returned `Entity` values to get components from storages as usual.
 for (ent, pos, vel) in (&*entities, &mut pos_storage, &vel_storage).join() {
     println!("Processing entity: {:?}", ent);
     *pos += *vel;
-    
+
     let mass: Option<&mut Mass> = mass_storage.get_mut(ent);
     if let Some(mass) = mass {
         let x = *vel / 300_000_000.0;

docs/tutorials/src/11_advanced_component.md

@@ -1,6 +1,6 @@
 # Advanced strategies for components
 
-So now that we have a fairly good grasp on the basics of Specs, 
+So now that we have a fairly good grasp on the basics of Specs,
 it's time that we start experimenting with more advanced patterns!
 
 ## Marker components
@@ -39,7 +39,7 @@ impl<'a> System<'a> for Sys {
         ReadStorage<'a, Velocity>,
         WriteStorage<'a, Position>,
     );
-    
+
     fn run(&mut self, (drag, velocity, mut position): Self::SystemData) {
         // Update positions with drag
         for (pos, vel, _) in (&mut position, &velocity, &drag).join() {
@@ -49,14 +49,14 @@ impl<'a> System<'a> for Sys {
         for (pos, vel, _) in (&mut position, &velocity, !&drag).join() {
             pos += vel;
         }
-    } 
+    }
 }
 ```
 
 Using `NullStorage` is recommended for marker components, since they don't contain
-any data and as such will not consume any memory. This means we can represent them using 
-only a bitset. Note that `NullStorage` will only work for components that are ZST (i.e. a 
-struct without fields). 
+any data and as such will not consume any memory. This means we can represent them using
+only a bitset. Note that `NullStorage` will only work for components that are ZST (i.e. a
+struct without fields).
 
 ## Modeling entity relationships and hierarchy
 
@@ -82,7 +82,7 @@ impl<'a> System<'a> for FollowTargetSys {
         ReadStorage<'a, Target>,
         WriteStorage<'a, Transform>,
     );
-    
+
     fn run(&mut self, (entity, target, transform): Self::SystemData) {
         for (entity, t) in (&*entity, &target).join() {
             let new_transform = transform.get(t.target).cloned().unwrap() + t.offset;
@@ -92,7 +92,7 @@ impl<'a> System<'a> for FollowTargetSys {
 }
 ```
 
-We could also model this as a resource (more about that in the next section), but it could 
+We could also model this as a resource (more about that in the next section), but it could
 be useful to be able to have multiple entities following targets, so modeling this with
 a component makes sense. This could in extension be used to model large scale hierarchical
 structure (scene graphs). For a generic implementation of such a hierarchical system, check
@@ -103,7 +103,7 @@ out the crate [`specs-hierarchy`][sh].
 ## Entity targeting
 
 Imagine we're building a team based FPS game, and we want to add a spectator mode, where the
-spectator can pick a player to follow. In this scenario each player will have a camera defined 
+spectator can pick a player to follow. In this scenario each player will have a camera defined
 that is following them around, and what we want to do is to pick the camera that
 we should use to render the scene on the spectator screen.
 
@@ -122,7 +122,7 @@ impl<'a> System<'a> for Render {
         ReadStorage<'a, Transform>,
         ReadStorage<'a, Mesh>,
     );
-    
+
     fn run(&mut self, (active_cam, camera, transform, mesh) : Self::SystemData) {
         let camera = camera.get(active_cam.0).unwrap();
         let view_matrix = transform.get(active_cam.0).unwrap().invert();
@@ -155,11 +155,11 @@ for entity in data.iter().map(|d| d.0) {
 
 There are a couple of limitations with this approach, the first being that we will always
 process all matched entities every frame (if this is called in a `System` somewhere). This
-can be fixed by using `FlaggedStorage` to maintain a sorted `Entity` list in the `System`. 
+can be fixed by using `FlaggedStorage` to maintain a sorted `Entity` list in the `System`.
 We will talk more about `FlaggedStorage` in the next [chapter][fs].
 
-The second limitation is that we do a `Vec` allocation every time, however this can be 
-alleviated by having a `Vec` in the `System` struct that we reuse every frame. Since we 
+The second limitation is that we do a `Vec` allocation every time, however this can be
+alleviated by having a `Vec` in the `System` struct that we reuse every frame. Since we
 are likely to keep a fairly steady amount of entities in most situations this could work well.
 
 [fs]: ./12_tracked.html

docs/tutorials/src/14_troubleshooting.md

@@ -2,25 +2,25 @@
 
 ## `Tried to fetch a resource, but the resource does not exist.`
 
-This is the most common issue you will face as a new user of Specs. 
-This panic will occur whenever a `System` is first dispatched, and one or 
+This is the most common issue you will face as a new user of Specs.
+This panic will occur whenever a `System` is first dispatched, and one or
 more of the components and/or resources it uses is missing from `World`.
 
 There are a few main reasons for this occurring:
 
-* Forgetting to call `setup` after building a `Dispatcher` or `ParSeq`. Make 
+* Forgetting to call `setup` after building a `Dispatcher` or `ParSeq`. Make
   sure this is always run before the first dispatch.
-* Not adding mandatory resources to `World`. You can usually find these by 
+* Not adding mandatory resources to `World`. You can usually find these by
   searching for occurrences of `ReadExpect` and `WriteExpect`.
 * Manually requesting components/resources from `World` (not inside a `System`),
   where the component/resource is not used by any `System`s, which is most common
-  when using the `EntityBuilder`. This is an artifact of how `setup` works, it 
-  will only add what is found inside the used `System`s. 
-  If you use other components/resources, you need to manually register/add these 
+  when using the `EntityBuilder`. This is an artifact of how `setup` works, it
+  will only add what is found inside the used `System`s.
+  If you use other components/resources, you need to manually register/add these
   to `World`.
 
-If all the reasons above have been rejected and the panic still occurs, you 
-can find out what exact resource is missing by adding a direct dependency on 
+If all the reasons above have been rejected and the panic still occurs, you
+can find out what exact resource is missing by adding a direct dependency on
 [`shred`][shred], and running the project with the nightly toolchain and enabling
 the `nightly` feature on `shred`.
 

src/bitset.rs

@@ -14,7 +14,7 @@ use crate::world::Index;
 macro_rules! define_bit_join {
     ( impl < ( $( $lifetime:tt )* ) ( $( $arg:ident ),* ) > for $bitset:ty ) => {
         impl<$( $lifetime, )* $( $arg ),*> Join for $bitset
-            where $( $arg: BitSetLike ),* 
+            where $( $arg: BitSetLike ),*
         {
             type Type = Index;
             type Value = ();

src/storage/entry.rs

@@ -110,7 +110,7 @@ where
     /// for (mut counter, _) in (counters.entries(), &marker).join() {
     ///     let counter = counter.or_insert_with(Default::default);
     ///     counter.increase();
-    ///         
+    ///
     ///     if counter.reached_limit() {
     ///         counter.reset();
     ///         // Do something