mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
rust/src/test/run-make/graphviz-flowgraph/f20.dot-expected.dot

28 lines
653 B
Plaintext
Raw Normal View History

Unit tests for flowgraph pretty printing. Each test works by rendering the flowgraph for the last identified block we see in expanded pretty-printed output, and comparing it (via `diff`) against a checked in "foo.dot-expected.dot" file. Each test post-processes the output to remove NodeIds ` (id=NUM)` so that the expected output is somewhat stable (or at least independent of how we assign NodeIds) and easier for a human to interpret when looking at the expected output file itself. ---- Test writing style notes: I usually tried to write the tests in a way that would avoid duplicate labels in the output rendered flow graph, when possible. The tests that have string literals "unreachable" in the program text are deliberately written that way to remind the reader that the unreachable nodes in the resulting graph are not an error in the control flow computation, but rather a natural consequence of its construction.
2014-05-05 17:00:14 +02:00
digraph block {
N0[label="entry"];
N1[label="exit"];
Update suffixes en masse in tests using `perl -p -i -e`
2015-02-18 05:42:01 -05:00
N2[label="expr 2usize"];
N3[label="expr 0usize"];
N4[label="expr 20usize"];
N5[label="expr [2usize, 0usize, 20usize]"];
Unit tests for flowgraph pretty printing. Each test works by rendering the flowgraph for the last identified block we see in expanded pretty-printed output, and comparing it (via `diff`) against a checked in "foo.dot-expected.dot" file. Each test post-processes the output to remove NodeIds ` (id=NUM)` so that the expected output is somewhat stable (or at least independent of how we assign NodeIds) and easier for a human to interpret when looking at the expected output file itself. ---- Test writing style notes: I usually tried to write the tests in a way that would avoid duplicate labels in the output rendered flow graph, when possible. The tests that have string literals "unreachable" in the program text are deliberately written that way to remind the reader that the unreachable nodes in the resulting graph are not an error in the control flow computation, but rather a natural consequence of its construction.
2014-05-05 17:00:14 +02:00
N6[label="local v"];
Update suffixes en masse in tests using `perl -p -i -e`
2015-02-18 05:42:01 -05:00
N7[label="stmt let v = [2usize, 0usize, 20usize];"];
Implement generalized object and type parameter bounds (Fixes #16462)
2014-08-27 21:46:52 -04:00
N8[label="expr v"];
Update suffixes en masse in tests using `perl -p -i -e`
2015-02-18 05:42:01 -05:00
N9[label="expr 20usize"];
N10[label="expr v[20usize]"];
N11[label="stmt v[20usize];"];
N12[label="block { let v = [2usize, 0usize, 20usize]; v[20usize]; }"];
Unit tests for flowgraph pretty printing. Each test works by rendering the flowgraph for the last identified block we see in expanded pretty-printed output, and comparing it (via `diff`) against a checked in "foo.dot-expected.dot" file. Each test post-processes the output to remove NodeIds ` (id=NUM)` so that the expected output is somewhat stable (or at least independent of how we assign NodeIds) and easier for a human to interpret when looking at the expected output file itself. ---- Test writing style notes: I usually tried to write the tests in a way that would avoid duplicate labels in the output rendered flow graph, when possible. The tests that have string literals "unreachable" in the program text are deliberately written that way to remind the reader that the unreachable nodes in the resulting graph are not an error in the control flow computation, but rather a natural consequence of its construction.
2014-05-05 17:00:14 +02:00
N0 -> N2;
N2 -> N3;
N3 -> N4;
N4 -> N5;
N5 -> N6;
N6 -> N7;
N7 -> N8;
N8 -> N9;
N9 -> N10;
Implement generalized object and type parameter bounds (Fixes #16462)
2014-08-27 21:46:52 -04:00
N10 -> N11;
N11 -> N12;
N12 -> N1;
Unit tests for flowgraph pretty printing. Each test works by rendering the flowgraph for the last identified block we see in expanded pretty-printed output, and comparing it (via `diff`) against a checked in "foo.dot-expected.dot" file. Each test post-processes the output to remove NodeIds ` (id=NUM)` so that the expected output is somewhat stable (or at least independent of how we assign NodeIds) and easier for a human to interpret when looking at the expected output file itself. ---- Test writing style notes: I usually tried to write the tests in a way that would avoid duplicate labels in the output rendered flow graph, when possible. The tests that have string literals "unreachable" in the program text are deliberately written that way to remind the reader that the unreachable nodes in the resulting graph are not an error in the control flow computation, but rather a natural consequence of its construction.
2014-05-05 17:00:14 +02:00
}
Reference in New Issue Copy Permalink