All writers implemented, along with resolving and validation.
TODO: SPIR-V Reader.
Bug: tint:1330
Change-Id: I8ba2f6023749474f80efb8a5422ac187e6c73a69
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/71820
Reviewed-by: David Neto <dneto@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
Kokoro: Ben Clayton <bclayton@google.com>
In GLSL, relational operators are only valid for scalar operands. For
vector operands, lessThan, greaterThan, etc must be used.
Bug: tint:1303
Change-Id: Ia800f89111630c756dc1b30ef0c6858fb520fb16
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/69561
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
Reviewed-by: Ben Clayton <bclayton@google.com>
Add a new 'Target' to the ast::CallExpression, which can be either an
Identifier or Type. The Identifier may resolve to a Type, if the Type is
a structure or alias.
The Resolver now resolves the CallExpression target to one of the
following sem::CallTargets:
* sem::Function
* sem::Intrinsic
* sem::TypeConstructor
* sem::TypeCast
This change will allow us to remove the type tracking logic from the WGSL
parser, which is required for out-of-order module scope declarations.
Bug: tint:888
Bug: tint:1266
Change-Id: I696f117115a50981fd5c102a0d7764641bb755dd
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/68525
Reviewed-by: David Neto <dneto@google.com>
Reviewed-by: James Price <jrprice@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Position maps to gl_Position in vertex shaders, and gl_FragCoord in
fragment shaders.
Bug: tint:1296
Change-Id: I22069af2c82bb03521f2721d16c29ba98c85f3f2
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/69280
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
Literals are now expressions, so in keeping with all the other
expression types, suffix the class name with Expression.
I'm not overly keen on requiring everything to have an Expression
suffix, but consistency is better than personal preference.
Note: this should have been part of 30848b6, but I managed to drop
this change instead of squashing it. Opps.
Bug: tint:888
Change-Id: Idfaf96abe165a6bf5028e60a160e7408aa2bf9db
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/68943
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: James Price <jrprice@google.com>
This cleans up the remnants of ArrayAccessorExpression which was renamed
in a838bb718.
Change-Id: Ie2c67a49e63774d8b153ec17c3185652708a91e5
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/68942
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: James Price <jrprice@google.com>
ConstructorExpression is abstract, and now only has a single class deriving
from it - TypeConstructorExpression. Just use that instead.
Bug: tint:888
Change-Id: I7ee52ad645bcd8a8a68710c63a1fdf834b5b2a24
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/68842
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: James Price <jrprice@google.com>
The object is not always an array. The index can be applied to vectors
too.
Change-Id: Ifb63d1862090d28cb48d692870e9dd01ddbce5df
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/68841
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: James Price <jrprice@google.com>
Just make Literal an expression. The ScalarConstructorExpression
provides no real value, aside from having a ConstructorExpression base
class that's common between ScalarConstructorExpression and
TypeConstructorExpression. TypeConstructorExpression will be folded into
CallExpression, so this hierarchy will serve no purpose.
First step in resolving the parser ambiguity of type-constructors vs
type-casts vs function calls.
Bug: tint:888
Change-Id: I2585d5ddbf6c0619a8f24c503e61ebf27c182ebe
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/68524
Kokoro: Kokoro <noreply+kokoro@google.com>
Reviewed-by: James Price <jrprice@google.com>
This will be needed for emitting UBO and SSBO interface
blocks.
Bug: tint:1223
Change-Id: I1cdc75b67a4fe612dcf8094a7d73b8bf1f85f40a
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/67242
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
And remove a whole load of const_cast hackery.
Semantic nodes may contain internally mutable fields (although only ever modified during resolving), so these are always passed by `const` pointer.
While all AST nodes are internally immutable, we have decided that pointers to AST nodes should also be marked `const`, for consistency.
There's still a collection of const_cast calls in the Resolver. These will be fixed up in a later change.
Bug: tint:745
Change-Id: I046309b8e586772605fc0fe6b2d27f28806d40ef
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/66606
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Ben Clayton <bclayton@chromium.org>
Reviewed-by: David Neto <dneto@google.com>
This is a modified version of the HLSL writer.
Basic types, arrays, entry points, reserved keywords, uniforms,
builtin uniforms, structs, some builtin functions, zero initialization
are implemented. Textures, SSBOs and storage textures in particular are
unimplemented. All the unit tests "pass", but the output is not correct
in many cases.
triangle.wgsl outputs correct vertex and fragment shaders that pass
GLSL validation via glslang. compute_boids.wgsl outputs a valid but not
correct compute shader.
Change-Id: I96c7aaf60cf2d4237e45d732e5f51b345aea0552
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/57780
Kokoro: Kokoro <noreply+kokoro@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
Reviewed-by: Ben Clayton <bclayton@google.com>
