The readers must not produce invalid ASTs.
If readers cannot produce a valid AST, then they should error instead.
If a reader does produce an invalid AST, this change catches this bad behavior early, significantly helping identify the root of the broken logic.
IsValid() made a bit more sense in the days where the AST was mutable, and was constructed by calling setters on the nodes to build up the tree.
In order to detect bad ASTs, IsValid() would have to perform an entire AST traversal and give a yes / no answer for the entire tree. Not only was this slow, an answer of 'no' didn't tell you *where* the AST was invalid, resulting in a lot of manual debugging.
Now that the AST is fully immutable, all child nodes need to be built before their parents. The AST node constructors now become a perfect place to perform pointer sanity checking.
The argument for attempting to catch and handle invalid ASTs is not a compelling one.
Invalid ASTs are invalid compiler behavior, not something that should ever happen with a correctly functioning compiler.
If this were to happen in production, the user would be utterly clueless to _why_ the program is invalid, or _how_ to fix it.
Attempting to handle invalid ASTs is just masking a much larger problem.
Let's just let the fuzzers do their job to catch any of these cases early.
Fixed: chromium:1185569
Change-Id: I6496426a3a9da9d42627d2c1ca23917bfd04cc5c
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/44048
Commit-Queue: Ben Clayton <bclayton@chromium.org>
Reviewed-by: David Neto <dneto@google.com>
* Disable "undefined-var-template" in code, rather than in build files
* Add back some missing headers required when building in this context
* Make sure gtest/gmock do not override the default runtime library
Change-Id: I12c05943fc1d2dee4733ae70db7da026f67e0dad
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/44180
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: Antonio Maiorano <amaiorano@google.com>
Make sure variables from the loop block remain in scope for
continuing block. Note that we need to do this because the continuing
block is a sibling of the loop body block in the AST, rather than a
child.
Added test.
Fixed: tint:526
Change-Id: If622995e3aac4cd3c06c2dbd87ffcaa36b0f09c5
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/43680
Commit-Queue: David Neto <dneto@google.com>
Reviewed-by: David Neto <dneto@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>
We now keep track of scopes as a tree of BlockInfos that track variables
declared in each scope. For loop scopes, we store the index of the first
variable (if any) that follows the first continue statement. Using this
data structure, when parsing expressions, we validate that used
variables in continuing blocks are not bypassed by a continue statement
in the parent loop block.
Also:
* Validate that continue statements are in a loop in TD. This error is
already caught by the spir-v writer, but better to catch it here.
* Add more utility functions to ProgramBuilder to make it easier to
write tests
Fixed: tint:17
Change-Id: I967bf2cfb63062bac8dcca113d074ba0fe2152e2
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/44120
Reviewed-by: Ben Clayton <bclayton@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
This change begins the work to move the reserved keyword remapping out of the writer and into the sanitizer transform.
If the transform::Renamer is in use, then these symbols should never have to be remapped - however for debugging purposes it is often nice to be able to emit code that isn't entirely mangled.
The logic in the msl writer will be removed as a followup change
Bug: tint:273
Change-Id: I76af03ff80388a48d9dd80a5b5fdfe21f3c8e7a0
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/43982
Reviewed-by: James Price <jrprice@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
Adding a flag to the tint sample binary that allows you to dump what
the inspector is reflecting about the bindings in a shader.
This has already helped me identify one blindspot in the validator.
BUG=tint:530
Change-Id: I6709f1d8f8391a1419d07abebf210e9e358e0861
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/43820
Reviewed-by: Ben Clayton <bclayton@google.com>
Auto-Submit: Ryan Harrison <rharrison@chromium.org>
Commit-Queue: Ben Clayton <bclayton@google.com>
Allows you to query type inheritance without having an instance of the type.
Also add TypeInfo::name. Helpful for decent error messages. Strings can be removed from NDEBUG builds if we consider them too large.
Change-Id: Ie501b37f46e63d956cc020f8c9b68e91737472f0
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/42920
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: James Price <jrprice@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
With this change, the base IntLiteral class now stores a u32, and
derived UintLiteral and SintLiteral are implemented in terms of it. This
will allow us to improve the current pattern of casting down to each
derived type to retrieve the value.
Change-Id: I0c1e56c5e04333a0d3d5f30a3fb28e784f785843
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/42900
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
You have to have the CloneContext in order to call ReplaceAll() in the first place. The overhead of capturing the pointer in the closure is negligible.
Cleans up the callsites.
Change-Id: I3a0fd808517d69f19756f590f3426e5ba226c57e
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/42840
Reviewed-by: James Price <jrprice@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
Emitted in the CWD when you run executables with the coverage enabled.
I find myself running the unittests from the project root a lot, and this file is annoying to skip when staging code.
Change-Id: I25557c941b2723aa300fcde827d281b054cbf2fd
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/42843
Reviewed-by: James Price <jrprice@google.com>
Commit-Queue: Ben Clayton <bclayton@google.com>
The chromium tests for static initializers get upset about the call to
ClassId::New() in a global variable initializer.
Instead, take the address of a unique 'token' variable to generate the
unique identifier.
This is similar to how things were before
https://dawn-review.googlesource.com/c/tint/+/42460
but of taking the address-of the token in the header, we're instead
taking the address-of inside the cpp file, avoiding the DLL issues
that 42460 addressed.
Change-Id: Id18c5b90b365b0960fac347729a4927528d34c07
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/42462
Auto-Submit: Ben Clayton <bclayton@google.com>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Ben Clayton <bclayton@google.com>
