mirror
/
rustc-dev-guide
mirror of https://github.com/rust-lang/rustc-dev-guide.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Improve instructions for adding a new test (#881) 

* Improve instructions for adding a new test

- Add a section for library tests
- Expand section on rustdoc tests

* Address review comments

- Say what should be considered a library test
- Mention adding error numbers to doc tests
- Link to #ui section
- Line wrapping

* Fix incorrect link

It shouldn't have been a link in the first place.

Co-authored-by: Yuki Okushi <huyuumi.dev@gmail.com>

Co-authored-by: Yuki Okushi <huyuumi.dev@gmail.com>
This commit is contained in:
Joshua Nelson 2020-09-19 19:40:17 -04:00 committed by GitHub
parent 27ff56d829
commit 9c5e356ed5
1 changed files with 14 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
src/tests/adding.md
View File

@ -29,15 +29,25 @@ rough heuristics:
- need to run gdb or lldb? use the `debuginfo` test suite - need to run gdb or lldb? use the `debuginfo` test suite
- need to inspect LLVM IR or MIR IR? use the `codegen` or `mir-opt` test - need to inspect LLVM IR or MIR IR? use the `codegen` or `mir-opt` test
suites suites
- need to run rustdoc? Prefer a `rustdoc` test - need to run rustdoc? Prefer a `rustdoc` or `rustdoc-ui` test.
Occasionally you'll need `rustdoc-js` as well.
- need to inspect the resulting binary in some way? Then use `run-make` - need to inspect the resulting binary in some way? Then use `run-make`
- For most other things, [a `ui` (or `ui-fulldeps`) test](#ui) is to be - Library tests should go in `library/${crate}/tests` (where `${crate}` is
preferred: usually `core`, `alloc`, or `std`). Library tests include:
- `ui` tests subsume both run-pass, compile-fail, and parse-fail tests - tests that an API behaves properly, including accepting various types or
having some runtime behavior
- tests where any compiler warnings are not relevant to the test
- tests that a use of an API gives a compile error, where the exact error
message is not relevant to the test. These should have an
[error number] (`E0XXX`) in the code block to make sure it's the correct error.
- For most other things, [a `ui` (or `ui-fulldeps`) test](#ui) is to be preferred:
- [`ui`](#ui) tests subsume both `run-pass`, `compile-fail`, and `parse-fail` tests
- in the case of warnings or errors, `ui` tests capture the full output, - in the case of warnings or errors, `ui` tests capture the full output,
which makes it easier to review but also helps prevent "hidden" regressions which makes it easier to review but also helps prevent "hidden" regressions
in the output in the output
[error number]: https://doc.rust-lang.org/rustdoc/unstable-features.html#error-numbers-for-compile-fail-doctests
## Naming your test ## Naming your test
We have not traditionally had a lot of structure in the names of We have not traditionally had a lot of structure in the names of