dawn-cmake/src/ast/loop_statement_test.cc

106 lines
2.9 KiB
C++
Raw Normal View History

// Copyright 2020 The Tint Authors.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
#include "src/ast/loop_statement.h"
ast: Replace IsValid() with TINT_ASSERT() 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>
2021-03-10 11:41:49 +00:00
#include "gtest/gtest-spi.h"
#include "src/ast/discard_statement.h"
#include "src/ast/if_statement.h"
#include "src/ast/test_helper.h"
namespace tint {
namespace ast {
namespace {
using LoopStatementTest = TestHelper;
TEST_F(LoopStatementTest, Creation) {
auto* body = Block(create<DiscardStatement>());
auto* b = body->Last();
auto* continuing = Block(create<DiscardStatement>());
auto* l = create<LoopStatement>(body, continuing);
ASSERT_EQ(l->body->statements.size(), 1u);
EXPECT_EQ(l->body->statements[0], b);
ASSERT_EQ(l->continuing->statements.size(), 1u);
EXPECT_EQ(l->continuing->statements[0], continuing->Last());
}
TEST_F(LoopStatementTest, Creation_WithSource) {
auto* body = Block(create<DiscardStatement>());
auto* continuing = Block(create<DiscardStatement>());
auto* l =
create<LoopStatement>(Source{Source::Location{20, 2}}, body, continuing);
auto src = l->source;
EXPECT_EQ(src.range.begin.line, 20u);
EXPECT_EQ(src.range.begin.column, 2u);
}
TEST_F(LoopStatementTest, IsLoop) {
auto* l = create<LoopStatement>(Block(), Block());
EXPECT_TRUE(l->Is<LoopStatement>());
}
TEST_F(LoopStatementTest, HasContinuing_WithoutContinuing) {
auto* body = Block(create<DiscardStatement>());
auto* l = create<LoopStatement>(body, nullptr);
EXPECT_FALSE(l->continuing);
}
TEST_F(LoopStatementTest, HasContinuing_WithContinuing) {
auto* body = Block(create<DiscardStatement>());
auto* continuing = Block(create<DiscardStatement>());
auto* l = create<LoopStatement>(body, continuing);
EXPECT_TRUE(l->continuing);
}
TEST_F(LoopStatementTest, Assert_Null_Body) {
ast: Replace IsValid() with TINT_ASSERT() 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>
2021-03-10 11:41:49 +00:00
EXPECT_FATAL_FAILURE(
{
ProgramBuilder b;
b.create<LoopStatement>(nullptr, nullptr);
},
"internal compiler error");
}
TEST_F(LoopStatementTest, Assert_DifferentProgramID_Body) {
EXPECT_FATAL_FAILURE(
{
ProgramBuilder b1;
ProgramBuilder b2;
b1.create<LoopStatement>(b2.Block(), b1.Block());
},
"internal compiler error");
}
TEST_F(LoopStatementTest, Assert_DifferentProgramID_Continuing) {
EXPECT_FATAL_FAILURE(
{
ProgramBuilder b1;
ProgramBuilder b2;
b1.create<LoopStatement>(b1.Block(), b2.Block());
},
"internal compiler error");
}
} // namespace
} // namespace ast
} // namespace tint