Linux perf tool version 3.2 introduced a new option "--log-fd" defaults
to 0, which leads to error "Failed opening logfd: Illegal argument" when
executing perf tests.
Set logfd to stderr to let perf test work.
Issue #1538
Naturaldocs isn't really that great but it seems easier to get
something working than with doxygen, for which we would need to
convert rust code to something C++ish. We probably want to just
write a rustdoc utility at some point.
On my machine I have two LLVM builds, one of regular HEAD and one
for Rust in ~/rust-llvm - by default CFG_LLVM_CONFIG is set to
/usr/local/bin/llvm-config which is wrong, because the probe for it
initially happens earlier in configure and succeeds (so putvar is called.)
This causes it to be emitted twice into the Makefile but the second
instance wins.
This splits mk/stageN.mk into host.mk and target.mk and makes
the build rules somewhat simpler - there's no more building from stageN
into stageN+1; instead we always build from stageN(host) to
stageN(target) then promote from stageN(target) to stageN+1(host).
Add a big honkin explaination right at the top of Makefile.in
This patch changes libuv's gyp build system to
make it's own makefiles. To generate them for rust,
run these commands. They requires python 2.x to
work:
$ mkdir -p src/rt/libuv/build
$ svn co http://gyp.googlecode.com/svn src/rt/libuv/build/gyp
$ ./etc/src/gyp_uv
Add a new src/test/pretty directory to hold just source files for testing the
pretty-printer.
Add a new pp-exact directive. When this directive is followed by a file name
it specifies a file containing the output that the pretty-printer should
generate. When pp-exact is not followed by a filename it says that the file
should pretty-print as written.
This replaces the make-based test runner with a set of Rust-based test
runners. I believe that all existing functionality has been
preserved. The primary objective is to dogfood the Rust test
framework.
A few main things happen here:
1) The run-pass/lib-* tests are all moved into src/test/stdtest. This
is a standalone test crate intended for all standard library tests. It
compiles to build/test/stdtest.stageN.
2) rustc now compiles into yet another build artifact, this one a test
runner that runs any tests contained directly in the rustc crate. This
allows much more fine-grained unit testing of the compiler. It
compiles to build/test/rustctest.stageN.
3) There is a new custom test runner crate at src/test/compiletest
that reproduces all the functionality for running the compile-fail,
run-fail, run-pass and bench tests while integrating with Rust's test
framework. It compiles to build/test/compiletest.stageN.
4) The build rules have been completely changed to use the new test
runners, while also being less redundant, following the example of the
recent stageN.mk rewrite.
It adds two new features to the cfail/rfail/rpass/bench tests:
1) Tests can specify multiple 'error-pattern' directives which must be
satisfied in order.
2) Tests can specify a 'compile-flags' directive which will make the
test runner provide additional command line arguments to rustc.
There are some downsides, the primary being that Rust has to be
functioning pretty well just to run _any_ tests, which I imagine will
be the source of some frustration when the entire test suite
breaks. Will also cause some headaches during porting.
Not having individual make rules, each rpass, etc test no longer
remembers between runs whether it completed successfully. As a result,
it's not possible to incrementally fix multiple tests by just running
'make check', fixing a test, and repeating without re-running all the
tests contained in the test runner. Instead you can filter just the
tests you want to run by using the TESTNAME environment variable.
This also dispenses with the ability to run stage0 tests, but they
tended to be broken more often than not anyway.
This will link to std and compile with the --test flag. Eventually the
run-pass/lib* tests will move here.
We could also put the std tests directly into the library and compile both a
library version and a test version, but I think this way will make for faster
builds.
Issue #428
