The `expect_` prefixes now clearly indicate when a method will internally error, or produce a valid AST object.
Verified by code coverage.
Bug: tint:282
Change-Id: Icbdae9db02bd48c69aec010a4f8fdc5a496125f8
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/32002
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Commit-Queue: Ben Clayton <bclayton@google.com>
... for those that will internally error if the grammar does not match,
otherwise will always return a valid AST object.
This helps identify whether the caller is expected to error or not.
Bug: tint:282
Change-Id: Ied94f717526a63033f2e6c9e94fca43dbf0b8f05
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/32001
Commit-Queue: Ben Clayton <bclayton@google.com>
Commit-Queue: dan sinclair <dsinclair@chromium.org>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Adds in method to get resource binding information for non-comparison
samplers along with tests. Additionally some of the infrastructure for
implementing an equivalent comparison sampler code path is included.
BUG=tint:257
Change-Id: I5775bbd6233e1014bea54c5281d460544ab8383d
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/31920
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
This CL fixes the issue with duplicate globals being emitted in HLSL if
used in multiple entry points. Tests are added for the other backends to
verify the issue does not exist there.
Bug: tint:297
Change-Id: I16d7504e8458fd375c6e1896758fe180ad963871
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/31880
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
Parse all decorations with the same function, and create a
`ast::DecorationList`. Once the parser has progressed to the consumer of
the decorations, we attempt to downcast these to the required type,
erroring if they're the wrong kind.
While the error message could be improved further, this greatly reduces
the headscratching around crbug.com/tint/291.
Also knocks another 223 lines off parser_impl.cc.
Bug: tint:291
Bug: tint:282
Change-Id: I7506faeb56d876e5446d900c7c134669a9db6409
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/31660
Commit-Queue: Ben Clayton <bclayton@google.com>
Commit-Queue: dan sinclair <dsinclair@chromium.org>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
`expect_block()` takes a start and end token, along with a function to parse a lexical block body.
This reduces code, keeps error messages consistent, and also gives us a future place to try resynchronising the parser so we can have more than one error emitted.
`expect_paren_block()` and `expect_brace_block()` are convenience helpers for providing the start and end tokens for common block types.
Bug: tint:282
Change-Id: I432a0301727b131a6fce875687b952dfc6889a4b
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/31736
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
This CL updates Tint to support the `texture_1d` format for sampled
textures. This is alongside the old `texture_sampled_1d` to allow
migration time.
The WGSL writer will always output the new form when converting to WGSL.
Bug: tint:286
Change-Id: I96f0308ad3c28ade96bcab7e24aa0b405e3c4f05
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/31380
Commit-Queue: dan sinclair <dsinclair@chromium.org>
Reviewed-by: Ryan Harrison <rharrison@chromium.org>
Updates the extraction code to assume that the StructType will be
wrapped by an AccessControlType. Tests are changed to match this
behaviour, and some minor naming clean up occured.
BUG=tint:257
Change-Id: I888ac2fae228531e956437afb937082a142d5736
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/31780
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
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>
I had originally created `Formatter` as an interface as I was intending to implement this differently for linux and windows (for terminal coloring).
Color printing is instead implemented by the `Printer` interface / PIMPL classes.
Replace the multi-boolean constructor with a `Style` struct, as this will make life easier when we want to add / remove flags.
Bug: tint:282
Change-Id: I630073ed7a76c023348b66e8a8517b00b2b6a0d2
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/31569
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
When generating a unary operation we need to make sure we correctly
generate the load otherwise the resulting SPIR-V will be invalid. This
CL adds the required GenerateLoadIfNeeded call into the unary
generation.
Bug: tint292
Change-Id: Ia04314726afdda8f63a78e8e52f996681373db6e
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/31620
Commit-Queue: dan sinclair <dsinclair@chromium.org>
Commit-Queue: David Neto <dneto@google.com>
Reviewed-by: David Neto <dneto@google.com>
Keep the `ParserImpl::error()` format identical to the old error style for now.
Use the explicit `ParserImpl::diagnostics()` method for the error message tests, updating the tests to match the new, improved output.
Bug: tint:282
Change-Id: Ia7e1237170f0f5203a8cfa256322df29e90e2791
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/31481
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Translate OpSpecConstantTrue, OpSpecConstantFalse, and OpSpecConstant.
The latter only can be used with integer or float scalars.
If the constant has a SpecId decoration, then generate a module-scope
decorated constant. Otherwise generate a module-scope constant without
decorations.
Register the ID so we know to use the declared const identifier in
expressions later in the module.
Bug: tint:156
Change-Id: Icd6e9b60225ced7ee99963c4f85cec1eb0e3ae6b
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/31541
Commit-Queue: David Neto <dneto@google.com>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
Diagnostics will be used for printing parser / validator error mesasges.
Diagnostics are collected into a `diag::List`, and can then be formatted into a human readable message with `diag::Formatter`.
Bug: tint:282
Change-Id: I8bbef3db22b72d62cb9467c878d9a346890589ad
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/31480
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
This includes a couple of position fixes in `lexer.cc`.
The source for identifiers (vars, params, etc) now refer to the identifier, not the first token of the construct.
Bug: tint:282
Change-Id: I58cb8422a4af1c7dc5f84431fd7f06b823b514c5
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/31444
Commit-Queue: Ben Clayton <bclayton@google.com>
Reviewed-by: dan sinclair <dsinclair@chromium.org>
