fix early type checks for comparison/logical ops in binaryOpNode

[skyyash]

Resolves #8445

Changes:

• add early type validation for comparison and logical operators in binaryOpNode.
• ordering operators (<, <=, >, >=) are now rejected when either operand is a vector, matching glsl rules.
• equality and logical operators also get matching dimension/base-type checks.
• errors are thrown via the existing fes helpers.

PR Checklist

• npm run lint passes
• Inline reference is included / updated
• Unit tests are included / updated

[p5-bot]

Continuous Release

CDN link

• https://raw.esm.sh/pr/p5@ea66bfe/lib/p5.min.js

Published Packages

• https://pkg.pr.new/p5@ea66bfe

Commit hash: ea66bfe

Previous deployments

6879d00

• https://raw.esm.sh/pr/p5@6879d00/lib/p5.min.js
• https://pkg.pr.new/p5@6879d00

e85a6e6

• https://raw.esm.sh/pr/p5@e85a6e6/lib/p5.min.js
• https://pkg.pr.new/p5@e85a6e6

---

This is an automated message.

[perminder-17]

Hi, thanks for your work on this! Do you think it would be worth adding two more cases?

1. Comparing two boolean values using <, etc. such as a < b where both a and b are booleans.
2. Comparing a boolean with a number using equalTo() or notEqual().

Both are invalid in GLSL, so catching them early with a strands error would be helpful? what do you think

[skyyash]

hi @perminder-17 , thanks for suggesting both cases. yes we should catch them early to log friendly errors.

happy to push follow up commit.

[perminder-17]

If you look at lines 177 to 183 in ir_builders.js

if (leftType.dimension === 1 && rightType.dimension > 1) {
  cast.node = leftStrandsNode;
  cast.toType = rightType;
} else if (rightType.dimension === 1 && leftType.dimension > 1) {
  cast.node = rightStrandsNode;
  cast.toType = leftType;

This code does type casting, where the dimensions get equalized. Because of this, the error message can become confusing.

For example:

if (color < 2) {
  // ...some operations
}

Currently we get: < is only defined for scalars. Got float4 < float4. But this is misleading, we should instead get Got float4 < float1, since that reflects the user's original types, not the post-cast types.

Can we take a snapshot of the original types before the typecasting happens, and use that snapshot in all the error messages, so this confusion doesn't happen? @skyyash Let me know what you think?

[skyyash]

@perminder-17 good catch, (i didnt noticed it).

when the pre-cast type is DEFER, i think the error message should fall back to the resolved post-cast types? what do you think?

preCastLeftType.baseType === BaseType.DEFER ? leftBase : preCastLeftType.baseType

since DEFER is an internal placeholder and Got defer4 < defer1 would mean nothing to the user...

[perminder-17]

i think the error message should fall back to the resolved post-cast types? what do you think?

Sounds good to me!