Remove indentation from doc comments.

The indentation in `command/bundle.rs` and `swap_chain.rs` causes
rustdoc to interpret these comments as code, which it then tries to
parse. Removing the indentation persuades it that they are text.

wgpu-core/src/command/bundle.rs

@@ -4,36 +4,36 @@
 
 /*! Render Bundles
 
-    ## Software implementation
+## Software implementation
 
-    The path from nothing to using a render bundle consists of 3 phases.
+The path from nothing to using a render bundle consists of 3 phases.
 
-    ### Initial command encoding
+### Initial command encoding
 
-    User creates a `RenderBundleEncoder` and populates it by issuing commands
-    from `bundle_ffi` module, just like with `RenderPass`, except that the
-    set of available commands is reduced. Everything is written into a `RawPass`.
+User creates a `RenderBundleEncoder` and populates it by issuing commands
+from `bundle_ffi` module, just like with `RenderPass`, except that the
+set of available commands is reduced. Everything is written into a `RawPass`.
 
-    ### Bundle baking
+### Bundle baking
 
-    Once the commands are encoded, user calls `render_bundle_encoder_finish`.
-    This is perhaps the most complex part of the logic. It consumes the
-    commands stored in `RawPass`, while validating everything, tracking the state,
-    and re-recording the commands into a separate `Vec<RenderCommand>`. It
-    doesn't actually execute any commands.
+Once the commands are encoded, user calls `render_bundle_encoder_finish`.
+This is perhaps the most complex part of the logic. It consumes the
+commands stored in `RawPass`, while validating everything, tracking the state,
+and re-recording the commands into a separate `Vec<RenderCommand>`. It
+doesn't actually execute any commands.
 
-    What's more important, is that the produced vector of commands is "normalized",
-    which means it can be executed verbatim without any state tracking. More
-    formally, "normalized" command stream guarantees that any state required by
-    a draw call is set explicitly by one of the commands between the draw call
-    and the last changing of the pipeline.
+What's more important, is that the produced vector of commands is "normalized",
+which means it can be executed verbatim without any state tracking. More
+formally, "normalized" command stream guarantees that any state required by
+a draw call is set explicitly by one of the commands between the draw call
+and the last changing of the pipeline.
 
-    ### Execution
+### Execution
 
-    When the bundle is used in an actual render pass, `RenderBundle::execute` is
-    called. It goes through the commands and issues them into the native command
-    buffer. Thanks to the "normalized" property, it doesn't track any bind group
-    invalidations or index format changes.
+When the bundle is used in an actual render pass, `RenderBundle::execute` is
+called. It goes through the commands and issues them into the native command
+buffer. Thanks to the "normalized" property, it doesn't track any bind group
+invalidations or index format changes.
 !*/
 #![allow(clippy::reversed_empty_ranges)]
 

wgpu-core/src/swap_chain.rs

@@ -4,32 +4,32 @@
 
 /*! Swap chain management.
 
-    ## Lifecycle
+## Lifecycle
 
-    At the low level, the swap chain is using the new simplified model of gfx-rs.
+At the low level, the swap chain is using the new simplified model of gfx-rs.
 
-    A swap chain is a separate object that is backend-dependent but shares the index with
-    the parent surface, which is backend-independent. This ensures a 1:1 correspondence
-    between them.
+A swap chain is a separate object that is backend-dependent but shares the index with
+the parent surface, which is backend-independent. This ensures a 1:1 correspondence
+between them.
 
-    `get_next_image()` requests a new image from the surface. It becomes a part of
-    `TextureViewInner::SwapChain` of the resulted view. The view is registered in the HUB
-    but not in the device tracker.
+`get_next_image()` requests a new image from the surface. It becomes a part of
+`TextureViewInner::SwapChain` of the resulted view. The view is registered in the HUB
+but not in the device tracker.
 
-    The only operation allowed on the view is to be either a color or a resolve attachment.
-    It can only be used in one command buffer, which needs to be submitted before presenting.
-    Command buffer tracker knows about the view, but only for the duration of recording.
-    The view ID is erased from it at the end, so that it's not merged into the device tracker.
+The only operation allowed on the view is to be either a color or a resolve attachment.
+It can only be used in one command buffer, which needs to be submitted before presenting.
+Command buffer tracker knows about the view, but only for the duration of recording.
+The view ID is erased from it at the end, so that it's not merged into the device tracker.
 
-    When a swapchain view is used in `begin_render_pass()`, we assume the start and end image
-    layouts purely based on whether or not this view was used in this command buffer before.
-    It always starts with `Uninitialized` and ends with `Present`, so that no barriers are
-    needed when we need to actually present it.
+When a swapchain view is used in `begin_render_pass()`, we assume the start and end image
+layouts purely based on whether or not this view was used in this command buffer before.
+It always starts with `Uninitialized` and ends with `Present`, so that no barriers are
+needed when we need to actually present it.
 
-    In `queue_submit()` we make sure to signal the semaphore whenever we render to a swap
-    chain view.
+In `queue_submit()` we make sure to signal the semaphore whenever we render to a swap
+chain view.
 
-    In `present()` we return the swap chain image back and wait on the semaphore.
+In `present()` we return the swap chain image back and wait on the semaphore.
 !*/
 
 #[cfg(feature = "trace")]