Remove the logic around `arrayLength()` being passed anything but a member accessor. Runtime arrays types cannot be used for variables nor parameters.
Add validator logic and test for runtime array parameters.
Adjust the validator error message so it doesn't include the field / variable name. This read weird, and the same information is already provided by the source.
Bug: tint:266
Bug: tint:252
Change-Id: Iecedb0524e10a67b4f8ad15635d67fe61e9d69d9
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/36420
Auto-Submit: Ben Clayton <bclayton@google.com>
Commit-Queue: dan sinclair <dsinclair@chromium.org>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Fix how handle usage is collected. OpImageQuerySize
is usable for *any* image that is either MS=1 or Sampled=0 or 2.
(Sampled=0 is not allowed by Vulkan).
So it's usable by storage images or multisampled image.
OpImageQuerySizeLod is usable by Sampled=1 MS=0 images, ie. sampled
images.
Fixed: tint:422
Change-Id: Ibfbcab2daa8b38f17758a0428a08cb9660496bac
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/36061
Auto-Submit: David Neto <dneto@google.com>
Commit-Queue: dan sinclair <dsinclair@chromium.org>
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
Helps with test grouping, and more importantly fixes a lint error about
the line length exceeding 80 characters, which cannot otherwise be
sensibly fixed as the formatter wants the fixture name to be unsplit.
Change-Id: I54b32e3516250b4064cd66a618f2239982aaf2d1
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/36381
Auto-Submit: Ben Clayton <bclayton@google.com>
Commit-Queue: dan sinclair <dsinclair@chromium.org>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Switch all remaining AST stack allocations in tests to using create<T>() which will automatically inject the current Source as the first parameter.
Most remaining uses of Source{} in the codebase are places where we need to fix.
Bug: tint:396
Change-Id: I24655800b50d6ad52e682a7339022972e9b354d9
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/36380
Commit-Queue: Ben Clayton <bclayton@google.com>
Commit-Queue: David Neto <dneto@google.com>
Auto-Submit: Ben Clayton <bclayton@google.com>
Reviewed-by: David Neto <dneto@google.com>
Texture buitins on depth textures always result in scalar f32.
Corresponding operations in SPIR-V always result in vec4<f32>.
When translating to Tint AST, wrap the generated texture builtin
in a type constructor to vec4, with the builtin result as the
x component.
Fixed: tint:411
Change-Id: Idf26a1cbc7e875bc8a97bf3c0b342c0220c6d4b7
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/35900
Auto-Submit: David Neto <dneto@google.com>
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
If you try to load it, return 1.0f instead.
Some cases of copy-object of intermediates are unhandled,
and will error out.
This is being done as an aid to porting GLSL Vulkan shaders
that do store 1 to gl_PointSize.
Fixed: tint:412
Change-Id: Ia33dc70bca630dccfbf11644f71d6be4b3f43f1a
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/35861
Commit-Queue: dan sinclair <dsinclair@chromium.org>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Auto-Submit: David Neto <dneto@google.com>
The interface for cloning a module was made significantly more complex in https://dawn-review.googlesource.com/c/tint/+/35502/ as some of the transforms required constructing symbols before the clone. This was temporary solution in 35502 was to copy the symbol table, then construct the new types, then perform the clone. This lead to a really messy callback interface, that was extremely error prone (e.g. lamda-capturing stack variables from the initializer callback that had been unwound).
Instead, clone the symbols as they're encountered. This may produce an entirely different set of identifiers, but no longer ever-grows the symbol list, and keeps the interface clean.
Bug: tint:396
Bug: tint:390
Change-Id: I54affd68ac3b730b649af9b47eba685c8a1d784a
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/35663
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
EXPECT_THAT(xxx, Eq(yyy)) << ToString(xxx);
is a less-idiomatic way of writing:
EXPECT_EQ(xxx, yyy);
The latter also provides a diff when two strings do not match.
Refactor these to:
auto got = xxx;
auto expect = yyy;
EXPECT_EQ(got, expect);
So that the error message clearly shows which one is the generated, and which one is the reference.
Change-Id: I781437ee63abdff3a67798b09e958be603c21313
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/35507
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Introduce `StatementBuilder`s , which may hold mutable state, before being converted into the immutable AST node on completion of the `BlockStatement`.
Bug: tint:396
Bug: tint:390
Change-Id: I0381c4ae7948be0de02bc13e54e0037a72baaf0c
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/35506
Reviewed-by: David Neto <dneto@google.com>
Commit-Queue: David Neto <dneto@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
In SPIR-V, coordinates for ImageRead, ImageFetch, ImageWrite are
integral. When they are unsigned, they must be converted to signed.
Fix tests for image sampling and dref sampling that used integer
coordinates. SPIR-V requires them to be floating point.
Bug: tint:109
Fixed: tint:346
Change-Id: If33c8970b9d8f7d934d3e582194fe6ed83eff7e8
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/35560
Commit-Queue: David Neto <dneto@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Auto-Submit: David Neto <dneto@google.com>
And swap the `decorations` and `members` parameters, as decorations come last for other constructors.
Parsers need fixing up.
Bug: tint:396
Bug: tint:390
Change-Id: Ie9b814c1de24b6c987f0fbb9e6f92da7c352caa2
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/35163
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: dan sinclair <dsinclair@chromium.org>