Subtracting float from product requires parentheses

[wrnrlr]

It looks like using a minus sign in an "additive_expression" wrapped in a "paren_expression" results in a parser error

// This ok:
let a = (3.0*2.0-(1.0)) * 1.0;
let b = (3.0*2.0+1.0) * 1.0;
// This fails:
let c = (3.0*2.0-1.0) * 1.0;

Parse Error: expected ')', found '-1.0'

This confused me for a while, and from what I understand from the grammar it should be allowed.

To reproduce this you can run this fragment shader with my slimshader or any such tool:

[[block]]
struct Uniforms {
  resolution: vec2<f32>; // in pixels
  playtime: f32; // in seconds
};

[[group(0), binding(0)]]
var<uniform> uniforms: Uniforms;

struct VertexOutput {
  [[location(0)]] coord: vec2<f32>;
  [[builtin(position)]] position: vec4<f32>;
};

[[stage(fragment)]]
fn main(in: VertexOutput) -> [[location(0)]] vec4<f32> {
  // This ok
  let a = (3.0*2.0-(1.0)) * 1.0;
  let b = (3.0*2.0+1.0) * 1.0;
  // This fails
  let c = (3.0*2.0-1.0) * 1.0;
  return vec4<f32>(1.0, 0.0, 0.0, 1.0);
}

[wrnrlr]

Strangely subtracting does work when you add whitespace after the minus sign:

// Okey
let c = (3.0*2.0 - 1.0) * 1.0;
// Fail
let c = (3.0*2.0-1.0) * 1.0;

[meshula]

parser preferred to parse the negative number, instead of expecting an operator or close paren? maybe the tokenizer isn't aware of the grammar context?

[jimblandy]

This is apparently per spec:

Note: literals are parsed greedily. This means that for statements like a -5 this will not parse as a minus 5 but instead as a -5 which may be unexpected. A space must be inserted after the - if the first expression is desired.

This is considered a bug in the spec, but it hasn't been fixed yet.

[jimblandy]

For the record, the general plan is to let constant expression folding handle the negation, so -5 will be treated not as a single token, but as a unary negation operator followed by a literal 5. Then, a-5 will be parsed as three tokens, and the - will be taken as a binary operator, not part of the integer literal.

There's a wrinkle: the largest negative i32 value is -2147483648, but its positive counterpart 2147483648 is out of range for i32, so it is not possible to write this value as an i32 and then negate it. To work around this, WGSL plans to specify that evaluation of constant expressions occurs in some anonymous wider type.

Since the behavior reported is per spec, I'll close this bug.

[teoxoy]

The spec issue has been resolved, reopening.

We should be able to tackle this once the const-expressions work lands.

[jimblandy]

The following passes with #4870:

fn f() {
    // This ok:
    let a = (3.0*2.0-(1.0)) * 1.0;
    let b = (3.0*2.0+1.0) * 1.0;
    // This fails:
    let c = (3.0*2.0-1.0) * 1.0;
}