spv-in upgrading AtomicIIncrement type

[schell]

Connections
Partially addresses #4489.
Follow up to #5702.

This creates a new module naga/src/front/atomic_upgrade.rs that begins the upgrade process by recursing through types and expressions previously marked during parsing.

This results in a Module that contains all needed types, but still does not validate, as the upgrades to expressions need to be applied to any expressions that use those expressions until all are resolved.
This results in a Module that validates, at least for the test case.

@jimblandy @cwfitzgerald :)

Checklist

• Run cargo fmt.
• Run cargo clippy. If applicable, add:
  • --target wasm32-unknown-unknown
  • --target wasm32-unknown-emscripten
• Run cargo xtask test to run tests.
• Add change to CHANGELOG.md. See simple instructions inside file.

[jimblandy]

There are bits and pieces of this that seem right - I think the type upgrading is almost right, for example - but I think the overall approach needs to be changed.

First of all, would be it feasible to restrict our focus for the time being to global variables with atomic or array-of-atomic types, leaving struct members and function arguments that are pointers to atomic values for later PRs?

In that case, what the SPIR-V front end needs to produce is a set of global variables whose types need to be upgraded. Atomics can only appear in workgroup and storage, so they can only really be held in global variables, we don't need to worry about locals or arguments. So instead of the FastHashMap<..., AtomicOp> structure you're producing now, you probably just need an IndexSet<Handle<GlobalVariable>>. The front end can discover the relevant global by looking into the Expression it just constructed for the atomic instruction's pointer operand.

(If the set will be iterated over, we prefer IndexSet over HashSet, to keep the iteration order deterministic.)

Then, the upgrade_atomics function needs to iterate over all those globals and upgrade their types. I think you shouldn't need to update any Expressions at all, so you shouldn't need to mess with any functions or expressions.

[schell]

Ok @jimblandy I'll try what you suggest with regard to tracking IndexSet<Handle<GlobalVariable>> instead of a map of AtomicOp.

[jimblandy]

The reason I think you won't need to update any expressions is that Naga IR Load expressions and Store statements both can operate on Atomics, so everything accessing the globals whose types you're whacking, whether Loads, Stores, or Atomics, should still be okay.

[jimblandy]

Two drive-by comments:

[jimblandy]

Okay, I've pushed a few more commits here. Please look them over, and if they seem all right, then we can land this.

Be sure to squash the changes when you land it!

[jimblandy]

Oh, um, I guess I should actually fix my review comments if I'm going to approve this

[schell]

@jimblandy these changes all make sense to me. Thank you!

[jimblandy]

Squashed and rebased.

Fixed up some cargo doc issues that I thought should have been caught by CI.