log::trace in allocator.rs panics on out-of-bounds

[yanchith]

Description
Found this while creating a trace for #658

On commit a7200bb (the one used by wgpu-rs master) wgpu-core sometimes panics with:

thread 'main' panicked at 'index out of bounds: the len is 2 but the index is 2', /home/yanchith/.cargo/git/checkouts/wgpu-53e70f8674b08dd4/a7200bb/wgpu-core/src/command/allocator.rs:33:21

wgpu-rs examples don't exhibit this behavior, but our application managed to trigger it.

The surrounding code is

    fn maintain(&mut self, lowest_active_index: SubmissionIndex) {
        for i in (0..self.pending.len()).rev() {
            if self.pending[i].1 < lowest_active_index {
                let cmd_buf = self.pending.swap_remove(i).0;
                log::trace!(
                    "recycling comb submitted in {} when {} is lowest active",
                    self.pending[i].1,
                    lowest_active_index,
                );
                self.recycle(cmd_buf);
            }
        }
    }

At a glance, it seems that the swap_remove removes the command buffer, but the code tries to access it again after being removed through the same index. This triggers a bounds check if the element was the last one, but even when this doesn't crash, the log message probably talks about a wrong command buffer.

Repro steps
Run trace in #658 in player, but set logging level to trace.

Expected vs observed behavior
No crashes that are not related to validation :)