WGSL: Const. eval. short-circuiting

[ErichDonGubler]

Description

Naga currently rejects programs with constant expressions such as this one:

const asdf = false && (123 / 0 > 0);

An uninformed reader might assume that dividing by zero yielding an error is expected. Indeed, Naga will happily report an error here:

Could not parse WGSL:
error: Division by zero
  ┌─ in.wgsl:1:24
  │
1 │ const asdf = false && (123 / 0 > 0);
  │                        ^^^^^^^ see msg

And yet, this is not standard behavior! The WGSL spec. clearly states that we should only be attempting const. eval. on the RHS of expressions when it cannot short-circuit. In the current WGSL spec.'s section 8.1.1:

The evaluation rule implies that short-circuiting operators && and || guard evaluation of their right-hand side subexpressions unless there is a subexpression that requires evaluation to determine a [static type](https://www.w3.org/TR/WGSL/#static-type).

Repro steps

Validate the above shader via naga as a file, i.e., in.wgsl. One can do this with a repo. checkout as follows:

$ cargo run -p naga-cli -- in.wgsl

Expected vs observed behavior

Already described, I hope!

Extra materials

Platform

[sagudev]

This will be complicated as evaluator already evals them to bool when doing logical and:

wgpu/naga/src/proc/constant_evaluator.rs

Lines 1925 to 1929 in 14abdd4

	(Literal::Bool(a), Literal::Bool(b)) => Literal::Bool(match op {
	BinaryOperator::LogicalAnd => a && b,
	BinaryOperator::LogicalOr => a || b,
	_ => return Err(ConstantEvaluatorError::InvalidBinaryOpArgs),
	}),

[teoxoy]

Related: #4394

[andyleiserson]

I took a look at this thinking it might be easier than #4394, but ran into some issues.

One difficulty is that we add expressions to the arena as soon as they are parsed (which happens bottom-up). Which means that in cases like const asdf = false && (123 / 0 > 0), we have a dilemma what to do with the expressions 123 / 0 and 123 / 0 > 0. Should they be recorded with ExpressionKind::Const, even though they're not valid constants? Or maybe with a new ExpressionKind::Invalid? Or relax the restriction that runtime expressions can't be put in a const arena, use ExpressionKind::Runtime, and check later in validation that there aren't any remaining references to runtime expressions?

Another difficulty is that replacing expressions with the constant they evaluate to hides information from later stages of processing. So if we short-circuit the evaluation of false && (0u + 1.0f > 0), we may not flag the incompatible types in the RHS. (I can't immediately find anything in the spec requiring that type checking occur before evaluating const exprs, but tint rejects this.)

A third difficulty is that function calls in const context (const asdf = false && bar(1)) are rejected during lowering. Tint allows this, although I think it is debatable. If bar(1) were a const-expression then it's clear that it shouldn't be evaluated unless it is necessary to determine a static type. But bar(1) is not a const-expression unless bar is a const-function.

[jimblandy]

Lowering to P2, as it's not a security risk, and we don't have evidence that this affects apps or demos.