typ::Types originating from ConvertType() will hold direct pointers to ast::Struct and ast::Aliase. These must not be used directly. Instead TypeNames should be created to refer to these.
Bug: tint:724
Change-Id: I7f511e0da56e5d3ac587cdb22b0baf38474bed1e
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/49746
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Fixed: tint:673
Change-Id: I5a58d9e504446ccff724e368b5ea2cf835d2271b
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/47768
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
Don't end the EXPECT_THAT() with `<< ToString(p->builder(), fe.ast_body());`
This string is already emitted in the error, and calling ast_body() a second time triggers an assert as the builder is already finalized.
Change-Id: Ied6aca73937e86aa6ce2d8cff8a09f67b5082349
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/47767
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: James Price <jrprice@google.com>
All includes from .cc to .h are preserved, even when transitively included.
It's clear that there are far too many includes in header files, and we should be more aggressive with forward declarations. tint:532 will continue to track this work.
There are, however, plenty of includes that have accumulated over time which are no longer required directly or transitively, so this change starts with a clean slate of *required* includes.
Bug: tint:532
Change-Id: Ie1718dad565f8309fa180ef91bcf3920e76dba18
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/44042
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
This generates intermediate variable to stuff the component into,
then a constant definition to evaluate the result for later use.
Bug: tint:3
Change-Id: If2e6bb24e2b1e621c3602509eb3237c40f53897b
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/41360
Auto-Submit: David Neto <dneto@google.com>
Commit-Queue: dan sinclair <dsinclair@chromium.org>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Will hold the mutable fields that currently reside in the otherwise immutable-AST.
Change the AST string methods to accept a `const semantic::Info&`. This is required as some nodes include type-resolved information in their output strings.
Bug: tint:390
Change-Id: Iba494a9c5645ce2096da0a8cfe63a4309a9d9c3c
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/39003
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Program is now immutable*, and remains part of the public Tint
interface.
ProgramBuilder is the mutable builder for Programs, and is not part of
the public Tint interface. ast::Builder has been folded into
ProgramBuilder.
Immutable Programs can be cloned into a mutable ProgramBuilder with
Program::CloneAsBuilder().
Mutable ProgramBuilders can be moved into immutable Programs.
* - mostly immutable. It still has a move constructor and move
assignment operator - required for practical usage - and the
semantic information on AST nodes is still mutable.
Bug: tint:390
Change-Id: Ia856c50b1880c2f95c91467a9eef5024cbc380c6
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/38240
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Enforce all places where Dawn passes in or returns a ast::Module, now takes a `const Program* ` or returns a `Program`.
As the end goal of all this is to have immutable Programs, all Program inputs take a pointer instead of moving the actual object.
As consumers of a Program are now all const, we have to const_cast to work around all the places we've been incorrectly mutating a ast::Module.
These const_casts are temporary, and will be fixed in the next set of changes.
Depends on https://dawn-review.googlesource.com/c/dawn/+/38522
Bug: tint:390
Change-Id: Ie05b112b16134937d1b601e9b713ea4ec4e1c677
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/38541
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>
This CL adds a Symbol to the identifier to represent the name. The name
still exists but will be removed in a future CL when the namers are in
place.
Change-Id: Ic3cc8ad0d99e3bea6eb1ff1ce212e7de67991aec
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/35460
Commit-Queue: dan sinclair <dsinclair@chromium.org>
Auto-Submit: dan sinclair <dsinclair@chromium.org>
Reviewed-by: Ben Clayton <bclayton@google.com>
The reason being that some tests called parse() twice, which will silently destruct the first parser.
Once the `Module` owns the AST nodes, the second call will end up deleting all the AST nodes. Tests would then perform use-after-free for the AST nodes belonging to the first parser / module.
There's no reason why the unique_ptr can't be returned, which is cleaner overall.
Bug: tint:335
Change-Id: I7ff2e9777a7ebeb76702f806294fe4c2c49bd7c9
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/33241
Auto-Submit: Ben Clayton <bclayton@google.com>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Commit-Queue: dan sinclair <dsinclair@chromium.org>
This CL adds the result_type type_name into the AST dump if available.
Bug: tint:310, tint:308
Change-Id: Iea678fd4f7a2dadbfca86f29043c75459c421cb3
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/32780
Reviewed-by: Sarah Mashayekhi <sarahmashay@google.com>
Commit-Queue: dan sinclair <dsinclair@chromium.org>
If is_const is true, then dump VariableConst{...
For ast::DecoratedVariable, dump "DecoratedVariableConst{..."
when it's const.
Change-Id: I8383e5bc989e4ee20e3a5812f346d5f9a7990dbb
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/30920
Commit-Queue: dan sinclair <dsinclair@chromium.org>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
This CL adds the parsing of structs with names. The parsing of type
aliased structs remains to allow for migration to the new system. The
named struct format is always emitted.
Bug: tint:175
Change-Id: Ic0579dedbd2dd0edc7dfd30bc2ec02972091e718
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/30341
Commit-Queue: dan sinclair <dsinclair@chromium.org>
Reviewed-by: David Neto <dneto@google.com>
Follow the actual SPIR-V type when computing a composite extract
instad of the canonicalized view in the optimizer's type manager.
Do this so we can generate the correct member name for a struct,
rather than using the member name for the other representative
struct type. The optimizer's type canonicalizer is insensitive to
struct member names.
Prompted by tint:213, for which the original case was an
access chain.
Bug: tint:3, tint:213
Change-Id: I8705c7ee655fe47c8b7a3658db524fe18833efdb
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/27603
Commit-Queue: David Neto <dneto@google.com>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Old way:
- struct decorated with BufferBlock
- Uniform storage class
New way
- struct decorated with Block
- StorageBuffer storage class
Also fixes the result type for an access chain.
Bug: tint:99
Change-Id: I2324ba94bb19b369d206313de798bdfec6099fe0
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/24605
Reviewed-by: dan sinclair <dsinclair@chromium.org>
When a type alias is created, map the SPIR-V type ID to the
type alias, not the underlying type. Only unpack the alias as
needed when inspecting the content structure to make values.
Bug: tint:3
Change-Id: I11011ddd190d89c81d3323f684a5e13f17dde09d
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/23582
Reviewed-by: dan sinclair <dsinclair@google.com>
This CL cleans up various formatting and lint errors.
Change-Id: Ieee14db90e36acc8b469d58abb84fcf3595321bb
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/23224
Reviewed-by: David Neto <dneto@google.com>
