commit | c41c7cdf31bf09df8438a8effc9523284ebc5719 | [log] [tgz] |
---|---|---|
author | Ben Clayton <bclayton@google.com> | Mon Jun 28 16:09:57 2021 +0000 |
committer | Tint LUCI CQ <tint-scoped@luci-project-accounts.iam.gserviceaccount.com> | Mon Jun 28 16:09:57 2021 +0000 |
tree | 1ebd4592041d948cec958ec70c27dcdbe0df4f8c | |
parent | 65cb20c1dbc948113bf26a02487d0ec2647001e1 [diff] |
reader/wgsl: Only resync if num errors less than limit As all loops in the parser require `synchronized_` to be true, don't set this to true if we've hit the maximum number of error diagnostics. This lets the parser bubble up as soon as the limit was reached, instead of only aborting once we finally reach the top level loop. ClusterFuzz has uncovered a number of cases where, in a loop, it can produce an error, then resynchronize, then error again on the next loop iteration. This produces more than the max limit of errors, and can stall the tests long enough to time out. No unit tests for this, as it requires a really contrived input to trigger, and to exhaustively catch all the places we now call maybe_set_synchronized() would result in a large colleciton of horrible tests. Instead, let ClusterFuzz do the testing. Fixed: chromium:1224031 Fixed: chromium:1224032 Fixed: chromium:1224042 Fixed: chromium:1224049 Fixed: chromium:1224050 Fixed: chromium:1224130 Fixed: chromium:1224131 Fixed: chromium:1224132 Fixed: chromium:1224144 Fixed: chromium:1224191 Change-Id: I63f160e28d13b85ee92e1b921239d7fb8ac22a08 Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/56070 Auto-Submit: Ben Clayton <bclayton@google.com> Kokoro: Kokoro <noreply+kokoro@google.com> Commit-Queue: Ben Clayton <bclayton@google.com> Reviewed-by: James Price <jrprice@google.com>
Tint is a compiler for the WebGPU Shader Language (WGSL).
This is not an officially supported Google product.
TINT_BUILD_SPV_READER
: enable the SPIR-V input reader (off by default)TINT_BUILD_WGSL_READER
: enable the WGSL input reader (on by default)TINT_BUILD_SPV_WRITER
: enable the SPIR-V output writer (on by default)TINT_BUILD_WGSL_WRITER
: enable the WGSL output writer (on by default)TINT_BUILD_FUZZERS
: enable building fuzzzers (off by default)Tint uses Chromium dependency management so you need to install depot_tools and add it to your PATH.
# Clone the repo as "tint" git clone https://dawn.googlesource.com/tint tint cd tint # Bootstrap the gclient configuration cp standalone.gclient .gclient # Fetch external dependencies and toolchains with gclient gclient sync
mkdir -p out/Debug cd out/Debug cmake -GNinja ../.. ninja # or autoninja
mkdir -p out/Debug cd out/Debug cmake ../.. make # -j N for N-way parallel build
mkdir -p out/Debug gn gen out/Debug autoninja -C out/Debug
If you are attempting fuzz, using TINT_BUILD_FUZZERS=ON
, the version of llvm in the XCode SDK does not have the needed libfuzzer functionality included.
The build error that you will see from using the XCode SDK will look something like this:
ld: file not found:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.0/lib/darwin/libclang_rt.fuzzer_osx.a
The solution to this problem is to use a full version llvm, like what you would get via homebrew, brew install llvm
, and use something like CC=<path to full clang> cmake ..
to setup a build using that toolchain.
The gn based work flow uses the Chromium toolchain for building in anticipation of integration of Tint into Chromium based projects. This toolchain has additional plugins for checking for style issues, which are marked with [chromium-style] in log messages. This means that this toolchain is more strict then the default clang toolchain.
In the future we will have a CQ that will build this work flow and flag issues automatically. Until that is in place, to avoid causing breakages you can run the [chromium-style] checks using the CMake based work flows. This requires setting CC
to the version of clang checked out by gclient sync
and setting the TINT_CHECK_CHROMIUM_STYLE
to ON
.
mkdir -p out/style cd out/style cmake ../.. CC=../../third_party/llvm-build/Release+Asserts/bin/clang cmake -DTINT_CHECK_CHROMIUM_STYLE=ON ../../ # add -GNinja for ninja builds
Please file any issues or feature requests at https://bugs.chromium.org/p/tint/issues/entry
Please see the CONTRIBUTING and CODE_OF_CONDUCT files on how to contribute to Tint.
Tint has a process for supporting experimental extensions.