software-mansion / software-mansion/TypeGPU

fix: Throw on coercing/casting runtime values to `bool`, and suggest directly comparing to the desired value

Open
#2,442 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

stability
Dominant language
TypeScript
Stars
3.2k
Forks
123
Avg merge
3d 5h
Merged PRs (30d)
34

Description

Handling undefined in shader functions is a whole set of problems. Because undefined as a value doesn't exist on the GPU, yet undefined behavior does, users can wrongly depend on checks against an empty array item under the assumption that it will fail, yet the GPU will happily read from outside of the bounds of the array and give a truthy value.

Let's say we have a function like this:

function foo() {
  'use gpu';
  const arr = [1, 2, 3];
  while (true) {
    if (!arr[i]) {
      break;
    }
    // ...
  }
}

Currently, we will generate the following WGSL:

fn foo() {
  var arr = array<i32>(1, 2, 3);
  while (true) {
    if (!arr[i]) { // WILL read outside of the array, potentially infinite loop
      break;
    }
    // ...
  }
}

It's very hard to exhaustively track whether something can or can't be undefined by tracing through the program, and then again we'd have to verify that devs don't depend on the value being undefined or not.

Solution

My current solution to this problem, is to recognize that coercing non-bool primitives to bool in WGSL is equivalent to comparing them to 0.

let a = bool(1);
// same thing
let b = 1 != 0;

When coercing numbers to bool in JavaScript, there are many more cases where the result can be false:

  • !!(0) -> false
  • !!(NaN) -> false
  • !!(undefined) -> false
  • (a few more...)

We can use that fact to nudge users in the right direction, to state their intent. I think we should throw a descriptive error each time a runtime-known value is coerced/cast into a boolean, and require devs to change it to a more explicit form.

What about comptime

Comptime-known values are fine to coerce to bools 👍

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files or tests are named. Start by locating the TypeScript handling for coercing or casting runtime-known values to bool during shader generation. Verify that comptime-known values remain allowed while runtime-known values produce a descriptive error, and add coverage for the stated unsafe array-check case.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
compilers, computer-graphics
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.