[naga] Remove non-essential override references via compaction

[andyleiserson]

Adds a mode to compaction that removes unused functions, global variables, and named types and overrides. This mode is used everywhere except the compaction at the end of lowering, where it is important to preserve unused items for type checking and other validation of the module.

Pruning all but the active entry point and then compacting makes process_overrides tolerant of missing values for overrides that are not used by the active entry point.

Fixes #5885

This change also removes the compact feature from naga (enables the associated code unconditionally) due to the new use of compaction for overrides and lack of clear justification for the feature flag. See the first comment for more discussion.

Testing
Adds several cases in the validation test to verify that compaction removes references to non-essential overrides. Also enables the relevant CTS tests, which are now passing.

Squash or Rebase? Rebase

Important TODOs

• The call to compact within the benchmark added by Update naga benchmarks and add a compaction benchmark #7715 needs to updated with the 2nd argument in this PR.
• This change should have two changelog entries: one for the overrides, and one for removal of the compact feature (assuming that's what we do).

Checklist

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy --tests. If applicable, add:
  • --target wasm32-unknown-unknown
• Run cargo xtask test to run tests.

[andyleiserson]

There is a question what to do about the compact feature. Currently wgsl-in requires compact, so in many environments it is already required. But when wgsl-in is not set, we need a strategy for controlling the use of compaction in process_overrides:

1. Remove the compact feature and build the associated functionality unconditionally, as this PR currently does.
2. Make process_overrides conditional upon the compact feature, and arrange for the feature to be set when necessary. (A change would be needed to the no-features clippy runs, because wgpu-hal uses process_overrides, but does not enable compact.)
3. Make process_overrides available unconditionally, but when built without the compact feature, specifying all overrides is required.
4. Make process_overrides conditional upon a new feature (overrides?) which would depend on compact.

I have listed in my order of preference, but I don't have all the context about use cases and build size concerns that might justify one of my non-preferred options.

[andyleiserson]

Some performance data: compacting all of the wgsl snapshot tests, with the reachability changes (#7674), before this change:

compact/shader: compact time:   [298.90 µs 299.67 µs 300.65 µs]
                        thrpt:  [472.03 MiB/s 473.57 MiB/s 474.78 MiB/s]

After this change, with !preserve_unused:

compact/shader: compact time:   [336.43 µs 337.32 µs 338.28 µs]
                        thrpt:  [419.06 MiB/s 420.25 MiB/s 421.37 MiB/s]
                 change:
                        time:   [+12.296% +12.679% +13.089%] (p = 0.00 < 0.05)
                        thrpt:  [-11.574% -11.253% -10.950%]
                        Performance has regressed.

Without the reachability changes, after this change, with !preserve_unused:

compact/shader: compact time:   [194.58 µs 195.04 µs 195.50 µs]
                        thrpt:  [691.40 MiB/s 693.02 MiB/s 694.64 MiB/s]

Performance of other stages (with this change; wgsl-in includes a compaction and is ~1% slower, validation and hlsl-out are unchanged):

front/shader: wgsl-in   time:   [8.8573 ms 8.8659 ms 8.8749 ms]
                        thrpt:  [21.790 MiB/s 21.812 MiB/s 21.833 MiB/s]
validate/shader: validation
                        time:   [719.47 µs 720.31 µs 721.13 µs]
                        thrpt:  [268.17 MiB/s 268.47 MiB/s 268.79 MiB/s]
back/shader: hlsl-out   time:   [1.4870 ms 1.5040 ms 1.5299 ms]
                        thrpt:  [92.661 MiB/s 94.255 MiB/s 95.334 MiB/s]

[ErichDonGubler]

@jimblandy has indicated in Firefox internal chat that he's overwhelmed with taking on review right now, so I'll race 'im on this one.

[ErichDonGubler]

My first round of review, expecting at least one more: LGTM, minus some nits that we should work out. I don't expect these to be laborious.

PR-level nits:

1. This review requests squash-and-merge, but some changes (like breaking out adjust_doc_comments) feel like good things to keep as their own commits. Is there a reason you think it's not helpful to keep these separate?
2. CHANGELOG entries now, please? 😀

I don't think I'll be adding more feedback items, unless my remaining review scope (examining the test coverage) yields something I'm not expecting.

[ErichDonGubler]

… I'm not opposed to rebase, although if we do rebase, I might do some additional squashing first.

Sounds completely reasonable; I'd expect that with the fixup-style commits we've been pushing. 🙂

(What does a rebase merge do with a merge commit?)

The merge commit should just be discarded, in the absence of needing to resolve conflicts.

[ErichDonGubler]

You may fire merge when ready!