I specifically found this to be an issue on the WebGPU backend, triggered by a buildbot running my PR:

Error: WGPU: validation error: Error while parsing WGSL: :87:32 error: type mismatch for argument 1 in call to 'tan_f32', expected 'f32', got 'vec2<f32>'
 let _10 : vec2<f32> = tan_f32(_V0);
                               ^^^
 - While validating [ShaderModuleDescriptor]
 - While calling [Device].CreateShaderModule([ShaderModuleDescriptor]).

The real reason this fails, is because of this:

The original builtin function tan() is polymorphic and supports vectors. We however, break that behavior and convenience feature by wrapping it in a non-polymorphic function tan_f32(). Doing some research, it seems WGSL does not support polymorphic user-defined functions. This means we have two options:

1. Add all possible variations of all possible builtin functions as wrappers.
2. Strip the _f32 suffix from the function calls, and delete all wrapper functions.

Obviously, my preference goes to option 2, and benefit from having also all f16-equivalents work for free. This would also allow us to delete a bunch of those wrappers (not all) in other backends, like OpenCL and Metal. Only a handful would be left when our internal name does not match the name of the builtin API function. I would even argue that we can rewrite those automatically as well in print_extern_call. I'd prefer a short remapping table in the code generator, over a list of wrappers.

On one note, the only native vector types that are supported are only vec2, vec3, and vec4. So if you'd make schedules that require longer vectors, that will still not work, but at least is not unexpected IMO.