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>
And replace the use of`ast::As(Decoration* deco)` with `Castable::As<T>()`.
These were used for dynamic casting, but is now replaced with Castable.
Change-Id: Ie5fe19ad4db4bc4d19f5386d2cfddaaf84b215d0
Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/34302
Reviewed-by: dan sinclair <dsinclair@chromium.org>
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>
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
Dan Sinclair