user0/rust
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

A few small improvements to the contributing docs

Browse source
This commit is contained in:
Ariel Ben-Yehuda 2017-12-20 21:22:32 +02:00
parent a3a7203e2c
commit f68e11b440
2 changed files with 64 additions and 14 deletions
Download patch file Download diff file Expand all files Collapse all files

46
src/test/COMPILER_TESTS.md
View file

@ -35,20 +35,24 @@ The error levels that you can have are:
## Summary of Header Commands
Header commands specify something about the entire test file as a
whole, instead of just a few lines inside the test.
whole. They are normally put right after the copyright comment, e.g.:
```Rust
// Copyright blah blah blah
// except according to those terms.
// ignore-test This doesn't actually work
```
### Ignoring tests
These are used to ignore the test in some situations, which means the test won't
be compiled or run.
* `ignore-X` where `X` is a target detail or stage will ignore the test accordingly (see below)
* `ignore-pretty` will not compile the pretty-printed test (this is done to test the pretty-printer, but might not always work)
* `ignore-test` always ignores the test
* `ignore-lldb` and `ignore-gdb` will skip the debuginfo tests
* `min-{gdb,lldb}-version`
* `should-fail` indicates that the test should fail; used for "meta testing",
where we test the compiletest program itself to check that it will generate
errors in appropriate scenarios. This header is ignored for pretty-printer tests.
* `gate-test-X` where `X` is a feature marks the test as "gate test" for feature X.
Such tests are supposed to ensure that the compiler errors when usage of a gated
feature is attempted without the proper `#![feature(X)]` tag.
Each unstable lang feature is required to have a gate test.
* `ignore-lldb` and `ignore-gdb` will skip a debuginfo test on that debugger.
Some examples of `X` in `ignore-X`:
@ -58,6 +62,22 @@ Some examples of `X` in `ignore-X`:
* Pointer width: `32bit`, `64bit`.
* Stage: `stage0`, `stage1`, `stage2`.
### Other Header Commands
* `min-{gdb,lldb}-version`
* `min-llvm-version`
* `must-compile-successfully` for UI tests, indicates that the test is supposed
to compile, as opposed to the default where the test is supposed to error out.
* `compile-flags` passes extra command-line args to the compiler,
e.g. `compile-flags -g` which forces debuginfo to be enabled.
* `should-fail` indicates that the test should fail; used for "meta testing",
where we test the compiletest program itself to check that it will generate
errors in appropriate scenarios. This header is ignored for pretty-printer tests.
* `gate-test-X` where `X` is a feature marks the test as "gate test" for feature X.
Such tests are supposed to ensure that the compiler errors when usage of a gated
feature is attempted without the proper `#![feature(X)]` tag.
Each unstable lang feature is required to have a gate test.
## Revisions
Certain classes of tests support "revisions" (as of the time of this
@ -109,6 +129,12 @@ fails, we will print out the current output, but it is also saved in
printed as part of the test failure message), so you can run `diff` and
so forth.
Normally, the test-runner checks that UI tests fail compilation. If you want
to do a UI test for code that *compiles* (e.g. to test warnings, or if you
have a collection of tests, only some of which error out), you can use the
`// must-compile-successfully` header command to have the test runner instead
check that the test compiles successfully.
### Editing and updating the reference files
If you have changed the compiler's output intentionally, or you are