[naga][metal] Annotate dot product functions as wrapped functions

[RiverDave]

Connections
related — #7105

Description
Similar to other wrapped math functions in #7012 I've followed the same structure/procedure with functions calculating dot product on integers. Some key changes:

• Introduce a mangled helper for integer vector dot: naga_dot_{int|uint}{N}(a, b) -> returns the scalar dot result.
• Emitted once per concrete type/width, re-used on call sites.
• Modify integer-vector dot emission to call the helper directly.
• Leave float vector dot mapping to MSL’s builtin dot unchanged (Added a brief comment to make this clear).
• Name mangling logic centralized (e.g., naga_dot_int3, naga_dot_uint4) and shared between call expr site and wrapper generation.

Testing
I required minimal testing — output metal files seem to have generated correctly with the proper helper. I'm still trying to figure out how testing works, but the emitted files seem to make sense.

Squash or Rebase? Rebase, after squashing everything except 4c6e527.

Checklist

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy --tests. If applicable, add:
  • --target wasm32-unknown-unknown
• Run cargo xtask test to run tests.
• If this contains user-facing changes, add a CHANGELOG.md entry.

[andyleiserson]

Thanks for the contribution! I commented with a few suggestions.

[andyleiserson]

We somehow need to add all the possible variants of the dot function to this list, not the prefix. It looks like the list is pub but we don't use it directly, so maybe make the list private, put a comment here saying DOT_FUNCTION variants are added below, and add something in the KeywordSet construction for them.

The list added here should somehow be bound to the set of possibilities that get_dot_wrapper_function_helper_name can return (so there's no risk that WGSL adds a new type in the future that gets added in one place but not the other). Maybe iterate ScalarSet::CONCRETE_INTEGER?

[RiverDave]

Done, Although I'm not entirely satisfied with the way I handled the vector sizes and scalar types to generate the static names:

const CONCRETE_INTEGER_SCALARS: [crate::Scalar; 4] = [
    crate::Scalar::I32,
    crate::Scalar::U32,
    crate::Scalar::I64,
    crate::Scalar::U64,
];

const CONCRETE_VECTOR_SIZES: [crate::VectorSize; 3] = [
    crate::VectorSize::Bi,
    crate::VectorSize::Tri,
    crate::VectorSize::Quad,
];

I tried the more "idiomatic" way through overloads::concrete_int_scalars and overloads::vector_sizes however the accessibility to that module doesn't seem to be possible from msl for some reason?

(I'm not overly familiar with rust so — any pointer would be greatly appreciated to handle that visibility thing).

[andyleiserson]

I extracted these functions to the type_methods module and updated the code to use them.

I also eliminated Box::leak. Leaking a handful of strings for a global data structure is not a problem, but I worry about the cost of reviewing/waiving false positives when using leak checkers.

[RiverDave]

Thanks a lot for the help! — excellent insight regarding calling ::leak indeed.

[andyleiserson]

I will wait a little bit in case there are any comments about my edits, but I plan to merge this by tomorrow.

[jimblandy]

Andy's two commits look fine to me.