Description
naga's WGSL backend emits f32/f16 constants as full decimal expansions (e.g. f32::MAX-scale guards emit a ~39-digit literal like 300000000000000000000000000000000000000f). Safari 26.5.2's WGSL lexer rejects long decimal float literals — "Expected one of '(', a literal, or an identifier" — so any wgpu-on-web module reaching Safari via runtime SPIR-V→WGSL (or wgsl-out) that contains such a constant fails to compile there, silently invalidating the pipeline. Chrome/Dawn and the WGSL spec accept the literal; the fault is WebKit's, but naga emitting exponent form (3e38f) would fix every wgpu web app immediately regardless of the Safari release timeline.
Standalone repro (spec-valid, Chrome-compiles both, Safari rejects the long one): WebKit bug filed separately.
Request: in the wgsl-out float-literal path, emit scientific/exponent notation (or cap decimal digit count) for large-magnitude constants. We currently post-process naga output at build time to do exactly this as a workaround.
300000000000000000000000000000000000000f (fails) vs 3e38f (succeeds)
Repro steps
https://kirodev.expanxia.com/dev/assets/probe/webkit_wgsl_literal_repro.html
Expected vs observed behavior
successful compilation vs failed to compile
Extra materials
n/a
Platform
ipad pro m2, iphone 12, 13, 14, 15
Description
naga's WGSL backend emits f32/f16 constants as full decimal expansions (e.g. f32::MAX-scale guards emit a ~39-digit literal like 300000000000000000000000000000000000000f). Safari 26.5.2's WGSL lexer rejects long decimal float literals — "Expected one of '(', a literal, or an identifier" — so any wgpu-on-web module reaching Safari via runtime SPIR-V→WGSL (or wgsl-out) that contains such a constant fails to compile there, silently invalidating the pipeline. Chrome/Dawn and the WGSL spec accept the literal; the fault is WebKit's, but naga emitting exponent form (3e38f) would fix every wgpu web app immediately regardless of the Safari release timeline.
Standalone repro (spec-valid, Chrome-compiles both, Safari rejects the long one): WebKit bug filed separately.
Request: in the wgsl-out float-literal path, emit scientific/exponent notation (or cap decimal digit count) for large-magnitude constants. We currently post-process naga output at build time to do exactly this as a workaround.
300000000000000000000000000000000000000f (fails) vs 3e38f (succeeds)
Repro steps
https://kirodev.expanxia.com/dev/assets/probe/webkit_wgsl_literal_repro.html
Expected vs observed behavior
successful compilation vs failed to compile
Extra materials
n/a
Platform
ipad pro m2, iphone 12, 13, 14, 15