Apply suggestions from code review

Co-authored-by: Andy Leiserson <aleiserson@mozilla.com>

Author: andyleiserson

wgpu-core/src/device/queue.rs

@@ -601,7 +601,7 @@ impl WebGpuError for QueueSubmitError {
 /// - [`Queue::submit`] just submits user-constructed [`CommandBuffer`]s.
 ///
 /// - [`Queue::prepare_surface_texture_for_present`] examines the surface
-///   texture being presented, and submit deferred initialization commands and
+///   texture being presented, and submits deferred initialization commands and
 ///   barriers to get it ready.
 ///
 /// - [`Queue::flush_writes_for_buffer`] and [`Queue::flush_pending_writes`]
@@ -637,7 +637,7 @@ pub(crate) struct PendingSubmission<'a> {
 
     /// Surface textures referenced by command buffers in this submission.
     ///
-    /// These need to be passed to the [`wgpu_hal::Queue::submit`], which
+    /// These need to be passed to [`wgpu_hal::Queue::submit`], which
     /// requires that the list contains no duplicates, so we store them in a
     /// `HashMap` keyed by `SurfaceTexture` address.
     surface_textures: FastHashMap<*const Texture, Arc<Texture>>,

wgpu-core/src/device/resource.rs

@@ -669,9 +669,11 @@ impl Device {
     /// Note that a `false` result here does *not* guarantee that no further activity will
     /// occur on the `Device`. A [`Device`] can be marked invalid at any time, even while
     /// locks are held, meaning that operations begun before the `Device` was marked
-    /// invalid will still generally run to completion. This is simply a consequence of
-    /// making [`Device::valid`] an `AtomicBool`, rather than an ordinary `bool` field
-    /// protected by the same locks that all other operations acquire.
+    /// invalid will still generally run to completion. This is a consequence of
+    /// making [`Device::valid`] an `AtomicBool`. It could be avoided by making
+    /// [`Device::valid`] an ordinary `bool` field protected by the same locks that
+    /// all other operations acquire, but we use an `AtomicBool` because there
+    /// are many device validity checks and we want those to be cheap. 
     pub fn is_valid(&self) -> bool {
         self.valid.load(Ordering::Acquire)
     }
@@ -916,7 +918,7 @@ impl Device {
         // However, checking device validity for this purpose is tricky. A device can be
         // marked invalid at any time, regardless of what locks are held. This means that,
         // even though queue submission does check device validity at the start (in
-        // `Queue::allocate_submission`), the submission will proceed even if the the
+        // `Queue::allocate_submission`), the submission will proceed even if the
         // device gets marked invalid after that check. Thus, other threads can observe
         // the queue becoming non-empty even after they have observed the device to be
         // invalid.