It's not possible to spell out NaNs or infinities in WGSL though.

I did run a manual test here: #2461 (comment).

We should also document that Literal::F32 and Literal::F64 must not be nan or infinity.

Should we? I keep going back and forth on what's best for IR documentation.
On the one hand we have code in the validator that enforces the invariants of the IR which is usually self-explanatory but sometimes quite involved.
On the other, it would be nice to see at a glance what those invariants are on the IR itself but I worry they will get out of sync or might be too lengthy.

So far I've been of the opinion that if validation covers it there is no need to document what the validation is already doing but let me know what you think!

In this case we'll also most likely get an extension + capability which will allow NaNs and infinities.
gpuweb/gpuweb#2259 (SPIR-V has SPV_KHR_float_controls; haven't looked into the other languages).

It's not possible to spell out NaNs or infinities in WGSL though.

Oh, that's true. If this change were more involved I would want to imitate the unit tests from analyzer.rs, but that doesn't seem worth it in this case. Maybe in the future we will be able to implement some coverage requirements!

On the other, it would be nice to see at a glance what those invariants are on the IR itself but I worry they will get out of sync or might be too lengthy.

Yes, this is a risk. On the balance, though, I think it's really valuable to have the lib.rs docs be everything one needs to work with the IR. They're not there yet, but it's not too much trouble to avoid losing ground as we make new changes.