Fix typos and update Beginner tutorials 2, 3

Tutorial 2 - Swapchain
  - Update `get_next_texture` to `get_current_frame`
  - Fix typos
Tutorial 3 - Pipeline
  - Add updated fields to `PipelineLayout` creation
Fix typos in News

docs/beginner/tutorial2-swapchain/README.md

@@ -17,23 +17,23 @@ struct State {
 impl State {
     // Creating some of the wgpu types requires async code
     async fn new(window: &Window) -> Self {
-        unimplemented!()
+        todo!()
     }
 
     fn resize(&mut self, new_size: winit::dpi::PhysicalSize<u32>) {
-        unimplemented!()
+        todo!()
     }
 
     fn input(&mut self, event: &WindowEvent) -> bool {
-        unimplemented!()
+        todo!()
     }
 
     fn update(&mut self) {
-        unimplemented!()
+        todo!()
     }
 
     fn render(&mut self) {
-        unimplemented!()
+        todo!()
     }
 }
 ```
@@ -249,7 +249,7 @@ We don't have anything to update yet, so leave the method empty.
 
 ```rust
 fn update(&mut self) {
-    // remove `unimplemented!()`
+    // remove `todo!()`
 }
 ```
 
@@ -367,11 +367,11 @@ wgpu::RenderPassColorAttachmentDescriptor {
 }
 ```
 
-The `RenderPassColorAttachmentDescriptor` has the `attachment` field which informs `wgpu` what texture to save the colors to. In this case we specify `frame.view` that we created using `swap_chain.get_next_texture()`. This means that any colors we draw to this attachment will get drawn to the screen.
+The `RenderPassColorAttachmentDescriptor` has the `attachment` field which informs `wgpu` what texture to save the colors to. In this case we specify `frame.view` that we created using `swap_chain.get_current_frame()`. This means that any colors we draw to this attachment will get drawn to the screen.
 
-This is the texture that will received the resolved output. This will be the same as `attachment` unless multisampling is enabled. We don't need to specify this, so we leave it as `None`.
+This is the texture that will receive the resolved output. This will be the same as `attachment` unless multisampling is enabled. We don't need to specify this, so we leave it as `None`.
 
-The `obs` field takes an `wpgu::Operations` object. This tells wgpu what to do with the colors on the screen (specified by `frame.view`). The `load` field tells wgpu how to handle colors store from the previous frame. Currently we are clearing the screen with a bluish color.
+The `ops` field takes a `wpgu::Operations` object. This tells wgpu what to do with the colors on the screen (specified by `frame.view`). The `load` field tells wgpu how to handle colors stored from the previous frame. Currently we are clearing the screen with a bluish color.
 
 <div class="note">
 
@@ -383,6 +383,6 @@ It's not uncommon to not clear the screen if the streen is going to be completel
 
 ## Challenge
 
-Modify the `input()` method to capture mouse events, and update the clear color using that. *Hint: you'll probably need to use `WindowEvent::CursorMoved`*
+Modify the `input()` method to capture mouse events, and update the clear color using that. *Hint: you'll probably need to use `WindowEvent::CursorMoved`*.
 
 <AutoGithubLink/>

docs/beginner/tutorial3-pipeline/README.md

@@ -117,9 +117,12 @@ let fs_module = device.create_shader_module(wgpu::util::make_spirv(&fs_spirv.as_
 One more thing, we need to create a `PipelineLayout`. We'll get more into this after we cover `Buffer`s.
 
 ```rust
-let render_pipeline_layout = device.create_pipeline_layout(&wgpu::PipelineLayoutDescriptor {
-    bind_group_layouts: &[],
-});
+let render_pipeline_layout =
+    device.create_pipeline_layout(&wgpu::PipelineLayoutDescriptor {
+        label: Some("Render Pipeline Layout"),
+        bind_group_layouts: &[],
+        push_constant_ranges: &[],
+    });
 ```
 
 Finally we have all we need to create the `render_pipeline`.
@@ -136,6 +139,7 @@ let render_pipeline = device.create_render_pipeline(&wgpu::RenderPipelineDescrip
         module: &fs_module,
         entry_point: "main",
     }),
+    // continued ...
 ```
 
 Two things to note here:
@@ -143,7 +147,6 @@ Two things to note here:
 2. The `fragment_stage` is technically optional, so you have to wrap it in `Some()`. I've never used a vertex shader without a fragment shader, but the option is available if you need it.
 
 ```rust
-    // continued ...
     rasterization_state: Some(
         wgpu::RasterizationStateDescriptor {
             front_face: wgpu::FrontFace::Ccw,
@@ -154,6 +157,7 @@ Two things to note here:
             clamp_depth: false,
         }
     ),
+    // continued ...
 ```
 
 `rasterization_state` describes how to process primitives (in our case triangles) before they are sent to the fragment shader (or the next stage in the pipeline if there is none). Primitives that don't meet the criteria are *culled* (aka not rendered). Culling helps speed up the rendering process by not rendering things that should not be visible anyway.
@@ -161,7 +165,6 @@ Two things to note here:
 We'll cover culling a bit more when we cover `Buffer`s.
 
 ```rust
-    // continued ...
     color_states: &[
         wgpu::ColorStateDescriptor {
             format: sc_desc.format,
@@ -170,11 +173,11 @@ We'll cover culling a bit more when we cover `Buffer`s.
             write_mask: wgpu::ColorWrite::ALL,
         },
     ],
+    // continued ...
 ```
 A `color_state` describes how colors are stored and processed throughout the pipeline. You can have multiple color states, but we only need one as we're just drawing to the screen. We use the `swap_chain`'s format so that copying to it is easy, and we specify that the blending should just replace old pixel data with new data. We also tell `wgpu` to write to all colors: red, blue, green, and alpha. *We'll talk more about*`color_state` *when we talk about textures.*
 
 ```rust
-    // continued ...
     primitive_topology: wgpu::PrimitiveTopology::TriangleList, // 1.
     depth_stencil_state: None, // 2.
     vertex_state: wgpu::VertexStateDescriptor {
@@ -327,14 +330,14 @@ impl ShaderData {
 fn main() -> Result<()> {
     // This tells cargo to rerun this script if something in /src/ changes.
     println!("cargo:rerun-if-changed=src/*");
-    
+
     // Collect all shaders recursively within /src/
     let mut shader_paths = [
         glob("./src/**/*.vert")?,
         glob("./src/**/*.frag")?,
         glob("./src/**/*.comp")?,
     ];
-    
+
     // This could be parallelized
     let shaders = shader_paths.iter_mut()
         .flatten()
@@ -355,10 +358,10 @@ fn main() -> Result<()> {
     // recently.
     for shader in shaders? {
         let compiled = compiler.compile_into_spirv(
-            &shader.src, 
-            shader.kind, 
-            &shader.src_path.to_str().unwrap(), 
-            "main", 
+            &shader.src,
+            shader.kind,
+            &shader.src_path.to_str().unwrap(),
+            "main",
             None
         )?;
         write(shader.spv_path, compiled.as_binary_u8())?;
@@ -382,6 +385,6 @@ I'm glossing over the code in the build script as this guide is focused on wgpu
 </div>
 
 ## Challenge
-Create a second pipeline that uses the triangle's position data to create a color that it then sends to the fragment shader to use for `f_color`. Have the app swap between these when you press the spacebar. *Hint: use*`in`*and*`out`*variables in a separate shader.*
+Create a second pipeline that uses the triangle's position data to create a color that it then sends to the fragment shader to use for `f_color`. Have the app swap between these when you press the spacebar. *Hint: use* `in` *and* `out` *variables in a separate shader.*
 
 <AutoGithubLink/>

docs/beginner/tutorial9-models/README.md

@@ -20,7 +20,7 @@ pub struct ModelVertex {
 
 impl Vertex for ModelVertex {
     fn desc<'a>() -> wgpu::VertexBufferDescriptor<'a> {
-        unimplemented!();
+        todo!();
     }
 }
 ```
@@ -469,7 +469,7 @@ The code in `main.rs` will change accordingly.
 
 ```rust
 render_pass.set_pipeline(&self.render_pipeline);
-render_pass.draw_model_instanced(&self.obj_model, 0..self.instances.len() as u32, &self.uniform_bind_group); 
+render_pass.draw_model_instanced(&self.obj_model, 0..self.instances.len() as u32, &self.uniform_bind_group);
 ```
 
 <AutoGithubLink/>

docs/news/README.md

@@ -2,7 +2,7 @@
 
 ## 0.6
 
-This took me way to long. The changes weren't difficult, but I had to do a lot of copy pasting. The main changes are using `queue.write_buffer()` and `queue.write_texture()` everywhere. I won't get into the nitty gritty, but you can checkout the [pull request](https://github.com/sotrh/learn-wgpu/pull/90) if you're interested.
+This took me way too long. The changes weren't difficult, but I had to do a lot of copy pasting. The main changes are using `queue.write_buffer()` and `queue.write_texture()` everywhere. I won't get into the nitty gritty, but you can checkout the [pull request](https://github.com/sotrh/learn-wgpu/pull/90) if you're interested.
 
 ## Added Pong Showcase
 
@@ -16,7 +16,7 @@ My perfectionism got in my way a bit with this one. I wasn't sure that what I wa
 
 ## 0.5!
 
-To many things changed to make note of them here. Check out [the 0.5 pull request](https://github.com/sotrh/learn-wgpu/pull/29) if you're curious about specifics. That being said, 2 things are worth mentioning directly: the y-axis now points up like with DirectX and Metal, and requesting an adapter and creating a device now use `Future`s. The tutorials have been updated as well as the code.
+Too many things changed to make note of them here. Check out [the 0.5 pull request](https://github.com/sotrh/learn-wgpu/pull/29) if you're curious about specifics. That being said, 2 things are worth mentioning directly: the y-axis now points up like with DirectX and Metal, and requesting an adapter and creating a device now use `Future`s. The tutorials have been updated as well as the code.
 
 ## Reworked lighting tutorial
 
@@ -72,4 +72,3 @@ I don't know if this is a change from 0.4, but you use `wgpu = "0.4"` line in de
 
 ## New/Recent Articles
 <RecentArticles/>
-