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>
In the future, CloneContext will be operating on `Program`s so a field called `mod` is poorly named.
CloneContext has a `src` member, so rename to `dst` to keep symmetry.
Bug: tint:390
Change-Id: Ic724f8a18b46ef719790394cdc810f7eb3681234
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/38364
Commit-Queue: David Neto <dneto@google.com>
Auto-Submit: Ben Clayton <bclayton@google.com>
Reviewed-by: David Neto <dneto@google.com>
CloneContext clones the AST, types, symbols and in the future semantic info.
3/4 of these are non-ast, so promote these up to the root.
Bug: tint:390
Change-Id: I49619796e6f81f9ab64f79413a12c87312cb1901
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/38361
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
We're seeing some chrome bots fail unittests in ways that suspiciously
look like dynamic casts are doing Wrong Things.
The ClassID::Of() logic depends on the linker folding away duplicate
compilation unit definitions based on ODR rules. If we were to somehow
end up with different definitions, then we'd have two or more different
ClassIDs for the same T type - leading to issues similar to what we're
seeing.
I'm not entirely sure why/how this could happen - and we've so far been
entirely unable to locally reproduce - but it _might_ have something to
do with the goma cache.
In an attempt to work around this, move the static symbol definition out
of a header-local-static and into the .cc file for each of the types.
Change-Id: If914d3045b9dac6fbe8824dac71153a768cfceb9
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/34563
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Commit-Queue: Ben Clayton <bclayton@google.com>
Deep-clones all `Node`s and `Type`s into a new module.
Instead of writing a million standalone tests that'll only ever test the
existing fields of each type, I've opted to write the tests using
wgsl<->ast<->wgsl conversion. This means the tests require the enabling
of TINT_BUILD_WGSL_READER and TINT_BUILD_WGSL_WRITER, but I believe this
is much easier to maintain.
I'm aware there are probably gaps in the tests, and that even full
coverage is likely to rapidly rot, so I've also added
fuzzers/tint_ast_clone_fuzzer.cc - a fuzzer based test that ensures that
all AST modules can be cloned with identical reproduction.
I've run this across 100 cores of a 3990x for 4 hours, fixing the
single issue it detected.
Note: Expressions do not currently clone their `TypeManager` determined
types. This is for two reasons:
(a) This initial CL is mahoosive enough.
(b) I'm uncertain whether we actually want to clone this info, or to
re-run the `TypeDeterminer` after each AST transform. Maybe it should
be optional. Time will tell.
Fixed: tint:307
Change-Id: Id90fab06aaa740c805d12b66f3f11d1f452c6805
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/33300
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Reviewed-by: David Neto <dneto@google.com>
The hand-rolled `AsBlah()`, `IsBlah()` methods will be migrated in future changes.
Change-Id: I078c100b561b50018771cc38c1cac4379c393424
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/34301
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Reduces the per-instance size for an extra vtable entry.
Change-Id: Ie087e0b8d8524adf85663ab1224fb0ae1a5e0000
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/34300
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Instead of just having a single `DecorationKind` for the first
derivation from `Decoration`, have a `DecorationKind` for every
decoration type.
Add `Decoration::IsKind()` to test whether the decoration is of, or
derives from the given kind.
Note, this change is originally by bclayton@ from
https://dawn-review.googlesource.com/c/tint/+/33201R=bclayton@google.com
Bug: tint:287
Change-Id: I69b51dfaa3f82ef4d61cda383b2f98f401013429
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/33280
Commit-Queue: dan sinclair <dsinclair@chromium.org>
Commit-Queue: Ben Clayton <bclayton@google.com>
Auto-Submit: dan sinclair <dsinclair@chromium.org>
Reviewed-by: Ben Clayton <bclayton@google.com>
A common base class is required to move from std::unique_ptr<> to raw pointers for AST types.
Also unifies a bunch of similar APIs.
Bug: tint:322
Change-Id: If829f8c3f22069adf62751365f1f1eeb646aba08
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/32660
Commit-Queue: Ben Clayton <bclayton@google.com>
Commit-Queue: dan sinclair <dsinclair@chromium.org>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Once a `Decoration` has been parsed, it'll be placed into a `DecorationList` and validated later in the parse. In order to create error diagnostics that refer back to the decoration, we need to know its source.
Bug: tint:282
Bug: tint:291
Change-Id: I38de708adbd041601b61d7e0a4d0402e9a2fe526
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/31722
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
This is the first step in unifying the way decorations are parsed - i.e. instead of parsing decorations in different ways based on the predicted grammar that follows, we can parse decorations blocks in a unified way, then later verify what we have is as expected.
`StructDecoration` has been transformed from an `enum class` to a proper class so it can derive from `Decoration`.
Bug: tint:282
Bug: tint:291
Change-Id: Iaf12d266068d03edf695acdf2cd21e6cc3ea8eb3
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/31663
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Commit-Queue: Ben Clayton <bclayton@google.com>
Ben Clayton
dan sinclair