feat: Expected type stack in WgslGenerator

[aleksanderkatan]

Closes #1510, #1508.

Changes:

• added expectedTypeStack that lets us infer the struct types of JS objects and array types of JS arrays,
• added generateTypedExpression function, that pushes to the expectedTypeStack, calls generateExpression, pops from expectedTypeStack and tries to coerce the result to the correct type,
• removed callStack,
• [!] removed the feature that wrapped JS objects in entry functions into Out struct by default,
• [!] removed some segments of WGSL generator that seemed to me like they did nothing (marked with github comments),
• renamed the internal prop of functions that held type conversion hints from argTypes to argConversionHint, renamed 'coerce' to 'convert-arguments-to-common-type',
• rewritten or removed some pre-existing tests.

Expressions that use generateTypedExpression:

• returns,
• if/while/for conditions,
• array constructors,
• struct constructors,
• TGSL function calls.

Expressions that do not:

• vectors and matrices (there are multiple possible expected types),
• infix operators (-||-),
• functions that do not provide a conversion hint (like std functions, -||-),
• other things that I did not think about.

I did not change how JS variables defined outside of TGSL are parsed, I think it can be separated to another ticket. Same goes for optimizing number casting.

I am not convinced about the current implementation of the expectedTypeStack:

• Firstly, (at least at this moment) it theoretically suffices to just store the top of the stack in the context and let generateTypedExpression swap it, since the stack is exclusively modified in this function.
• Secondly, in its current form it is not applicable in many cases, especially when the type of the current expression is unknown, or when the expression could be of multiple types.
• Finally, it is not a reliable way of knowing what should the type of the current expression be:

let a = d.u32();
a = (1+2);

when generating the code for (1+2), the stack is empty, and the existence of the stack might mislead developers to think that it would hold u32 in this case. If we allowed unknown type and multiple types to be on the stack, we would be able to update this stack at all times. It would require many more changes, especially to std functions and vec/mat constructors that currently have no argTypes (as most of them cannot be given a single signature, they have overloads).
Let me know what direction would you like this taken to.

[aleksanderkatan]

🙄

[iwoplaza]

This is spectacular, makes things so much more robust now 👏👏👏

[reczkok]

Amazing work! 🙇

[reczkok]

Maybe we create something like:

export function isDualImpl<T extends (...args: unknown[]) => unknown>(
  value: unknown | TgpuDualFn<T>,
): value is TgpuDualFn<T> {
  const internal = (value as TgpuDualFn<T>)?.[$internal];
  return !!(value as TgpuDualFn<T>)?.[$internal] &&
    'jsImpl' in internal &&
    'gpuImpl' in internal &&
    'argConversionHint' in internal;
}

This sound useful and would clean up our types here (and potentially in other places - I didn't check)

    if (!isDualImpl(callee.value)) {
      throw new Error(
        `Function ${String(callee.value)} ${
          getName(callee.value)
        } has not been created using TypeGPU APIs. Did you mean to wrap the function with tgpu.fn(args, return)(...) ?`,
      );
    }

    // Other, including tgsl functions, std and vector/matrix schema calls.
-    const argConversionHint = callee.value[$internal]
-      ?.argConversionHint as FnArgsConversionHint ?? 'keep';
+    const argConversionHint = callee.value[$internal].argConversionHint;
...
-      const fnRes =
-      (callee.value as unknown as (...args: unknown[]) => unknown)(
-        ...convertedArguments,
-      ) as Snippet;
+      const fnRes = (callee.value)(
+        ...convertedArguments,
+      ) as Snippet;

[iwoplaza]

Dual impls are not the only callables (e.g., tgpu.fn), so this was breaking a lot of tests. I guess we'd have to check for all callables, but we can do that in another pull request.