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>
Instead of validating all global variables and then functions,
validate global declarations in the order they were added to the AST.
This fixes false-positive "redeclared identifier" errors when a global
variable is declared after a function that declares a variable of the
same name, and false-negative "identifier not declared" errors when a
global variable is declared after a function that tries to use it.
Change-Id: Ibf5e5265bc2f8ca892096f0420757b70e1984525
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/41302
Commit-Queue: James Price <jrprice@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>
Despite `tint::ast::type::Type` being in the AST namespace, these classes are clearly not AST nodes:
* They don't derive from ast::Node
* They're deduplicated by the type manager
* None of the types have an Source - they have no lexical declaration point
* The fact we have `ast::Struct` and `ast::type::Struct` clearly demonstrates what is an AST node, and what is a type.
* We have code scattered in the codebase (TypeDeterminer, writers, etc) that create new types after parsing - so clearly not part of the original syntax tree.
Types in tint are closer to being semantic info, but due to the parse-time generation of types, and tight dependency of ast::Nodes to types, I'd be reluctant to class these as semantic info. Instead, put these into a separate root level `tint::type` namespace and `src/tint` directory.
The fact that types exist in the ast::Module has already caused bugs (https://dawn-review.googlesource.com/c/tint/+/37261). This is a first step in separating out types from the ast::Module.
Bug: tint:390
Change-Id: I8349bbbd1b19597b8e6d51d5cda0890de46ecaec
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/38002
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Automatically prints a newline at the end of the last diagnostic in a list. Defaults to true.
Disabled for many tests that assume no newline at end of string.
Change-Id: Id1c2f7771f03f22d926fafc2bebebcef056ac5e8
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/37260
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Commit-Queue: Ben Clayton <bclayton@google.com>
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>
We've been using |blah| in various places to markup code, however this is not doxygen markup. So instead:
* If the code links to a parameter, use `blah`.
* If the code links to a member field, use #blah.
* If the code links to a method use blah().
* If the code is somewhere unlinkable use `blah`.
Change-Id: Idac748a4c2531b5bae77e1a335e3d3ef6fab48b6
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/33787
Commit-Queue: dan sinclair <dsinclair@chromium.org>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Reviewed-by: David Neto <dneto@google.com>
Unlike error strings, diagnostics can:
* Describe more than one error
* Be printed with colors
* Highlight (`^^^`) the particular error on the line
* Can have separate severities
Change-Id: I4ead391ffbe190e55f79c5f23536a4524768478d
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/33820
Commit-Queue: David Neto <dneto@google.com>
Reviewed-by: David Neto <dneto@google.com>
