Also check for Stat() failure in a few more places. This way, ninja doesn't print two "ninja: error: " lines if stat() fails during a build. It also makes it easier to keep the stat tests quiet. Every caller of Stat() needs to explicitly log the error string if that's desired.
Patch #933 fixed a crash with duplicate edges by not adding edges to the graph if all the edge's outputs are already built by other edges. However, it added the edge to the out_edges of the edge's input nodes before deleting it, letting inputs refer to dead edges. To fix, move the check for deleting an edge above the code that adds inputs. Expand VerifyGraph() to check that nodes don't refer to edges that aren't present in the state.
Fixes #867, both the crashes and "[stuck]" issues. The problem was that a duplicate edge would modify the in_edge of the outputs of the new build rule, but the edge corresponding to the old build rule would still think that the in_edge points to itself. `old_edge->outputs_->in_edge()` would not return `old_edge`, which confused the scan logic. As fix, let `State::AddOut()` reject changing in_edge if it's already set. This changes behavior in a minor way: Previously, if there were multiple edges for a single output, the last edge would be kept. Now, the first edge is kept. This only had mostly-well-defined semantics if all duplicate edges are the same (which is the only case I've seen in practice), and for that case the behavior doesn't change. For testing, add a VerifyGraph() function and call that every time any test graph is parsed. That's a bit more code than just copying the test cases from the bug into build_test.cc, but it also yields better test coverage overall.
Ninja currently uses googletest for testing. That makes building ninja_test somewhat annoying since it requires that one passes --with-gtest PATH to configure. It turns out just implementing the bits of googletest that ninja uses needs about the same amount of code than making the --with-gtest flag in configure.py work and making googletest print test results in a way we want (!) In addition to making configuration simpler, this also makes compiling tests much faster: On my system, touching src/build_test.cc (the slowest file to build in ninja) and rebuilding ninja_tests is twice as fast than without this patch. Building all is noticeably faster too: 5.6s with this patch, 9.1s without this patch (38% faster). The most noticeable things missing: EXPECT_* and ASSERT_* don't support streaming notes to them with operator<<, and for failing tests the lhs and rhs are not printed. That's so that this header does not have to include sstream, which slows down building ninja_test almost 20%. If this turns out to be annoying, we can maybe add it.
It's the only piece that cares about the current time.
.build_log load time 350ms -> 17ms, filesize 197MB -> 1.6MB on Mac. On Windows, it's 500ms -> 20ms. Makes the build log a lot less useful for scripts, but there could be a tool for use cases that need log information. A prototype of such a tool is in nico@1b243d3 The hash function is 64bit murmurhash2. Assuming that that different commands get the same hash only by chance, it's is very unlikely for two different commands to hash to the same value with a 64bit hash.
- Delete the old "Tokenizer" code. - Write separate tests for the lexer distinct from the parser. - Switch the parser to use the new code. - New lexer error output has file:line numbers so e.g. Emacs can jump your editor to the syntax error. - The EvalEnv ($-interpolation) code is now part of the lexer as well.