skia2/resources/sksl/errors/ArrayUnspecifiedDimensions.sksl

in int arrUnsized[];
in int arrFloat[1.];
in int arrBool[true];

int unsized_in_expression() { return int[](0)[0]; }
Disallow multi-dimensional arrays in SkSL. GLSL only allows one-dimensional arrays. This CL lowers SkSL's array dimensionality limit from eight to one, and fixes all the tests that this breaks. The rest of the code still technically supports arbitrarily-deep array dimensionality; there are many opportunities for code cleanup and simplification in followup CLs. Change-Id: I0fc31e4626649ec69d40c5f5597b3924de298df0 Bug: skia:11026 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/340339 Commit-Queue: John Stiles <johnstiles@google.com> Reviewed-by: Ethan Nicholas <ethannicholas@google.com> Auto-Submit: John Stiles <johnstiles@google.com> 2020-12-03 15:40:28 +00:00			`in int arrUnsized[];`
Disallow unsized array dimensions on size fields past the frontmost. This was slightly complicated by the fact that this syntax indicates an array with a known size: float[] x = float[](1, 2, 3, 4); Of course, the size is 4; it's just never explicitly stated in the code. (The SkSL parser never actually deduces the size, but it doesn't apparently have a need to; we don't do much in the way of optimization for arrays.) However, this prevents us from simply failing whenever we parse "[]" in non-builtin code; we need to keep scanning and see if the variable is initialized. We already check this in the ArrayConstructors.sksl test file. Change-Id: I5b86958e81bd9bf5edf28a617cecf95c1875583e Bug: skia:10957 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/335240 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: John Stiles <johnstiles@google.com> Auto-Submit: John Stiles <johnstiles@google.com> 2020-11-17 16:33:49 +00:00			`in int arrFloat[1.];`
			`in int arrBool[true];`
Enforce (valid) array sizes in many more places Unsized arrays are now allowed in exactly one place: On the declaration of an interface block. This satisfies the one existing use-case, which is the gl_in (sk_in) declaration for geometry shaders. There is no other useful scenario, and most of our backends don't support them anyway. Several spots were using less strict checks when attaching sizes to arrays, allowing for zero or negative-sized arrays, so those are all fixed now. The existing tests that initialize arrays are still a problem, because Metal doesn't support that (neither does GLES2). Also, ArrayConstructors has gone from generating an error in the Vulkan backend, to invalid SPIR-V. Bug: skia:11013 Bug: skia:11127 Change-Id: Ib08dfe9aeec96bf605661665d6f166419d27e8bc Reviewed-on: https://skia-review.googlesource.com/c/skia/+/353817 Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: John Stiles <johnstiles@google.com> 2021-01-14 19:18:10 +00:00
			`int unsized_in_expression() { return int[](0)[0]; }`