Expanding the test infrastructure for a "fancy suite" #10434
Labels
A-testsuite
Area: The testsuite used to check the correctness of rustc
Comments
|
+1 -- just improving how cross-crate tests work would be a plus. I find the current way (aux-build) pretty awkward and always have to look up how it works :-) |
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Nov 19, 2013
This infrastructure is meant to support runnings tests that involve various interesting interdependencies about the types of crates being linked or possibly interacting with C libraries. The goal of these make tests is to not restrict them to a particular test runner, but allow each test to run its own tests. To this end, there is a new src/test/run-make directory which has sub-folders of tests. Each test requires a `Makefile`, and running the tests constitues simply running `make` inside the directory. The new target is `check-stageN-rmake`. These tests will have the destination directory (as TMPDIR) and the local rust compiler (as RUSTC) passed along to them. There is also some helpful cross-platform utilities included in src/test/run-make/tools.mk to aid with compiling C programs and running them. The impetus for adding this new test suite is to allow various interesting forms of testing rust linkage. All of the tests initially added are various flavors of compiling Rust and C with one another as well as just making sure that rust linkage works in general. Closes rust-lang#10434
|
cc me |
flip1995
pushed a commit
to flip1995/rust
that referenced
this issue
Mar 24, 2023
Remove `snippet_with_macro_callsite` `snippet_with_context` is used instead to support nested macro calls. changelog: None
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now we have the ability to test rust programs that consist of entirely rust source code through the various
src/test/XXXsuites. I've been thinking recently that we may want a "fancy suite" which supports lots of custom-building options like mixing C/C++ with rust in various flavorful ways. Some examples of this would be:#[no_std]and friends (but perhaps limited support for I/O).I was thinking something along the lines of
src/test/fancy-suite/testname/Makefilewould basically be the "run this test" rules. Each test would be responsible for doing its own validation of output/errors/whatnot.I'm not sure if this really warrants a whole new style of testing infrastructure, but some of the use cases that'd be nice to test I don't know how to test today. Although perhaps in theory they could all be written in just a rust program in
src/test/run-pass, but the makefiles/such will probably need defines for the rustc and friends to use.The text was updated successfully, but these errors were encountered: