Stick with "directives"

Don't mix both "headers" and "directives" which is needlessly confusing.

src/SUMMARY.md

@@ -24,7 +24,7 @@
     - [Best practices](./tests/best-practices.md)
     - [Compiletest](./tests/compiletest.md)
         - [UI tests](./tests/ui.md)
-        - [Test headers](./tests/headers.md)
+        - [Test headers](./tests/directives.md)
     - [Ecosystem testing](./tests/ecosystem.md)
         - [Crater](./tests/crater.md)
         - [Fuchsia](./tests/fuchsia.md)

src/tests/adding.md

@@ -73,7 +73,7 @@ A few things to notice about our test:
 
 - The top should start with a short comment that [explains what the test is
   for](#explanatory_comment).
-- The `//@ edition:2018` comment is called a [directive](headers.md) which
+- The `//@ edition:2018` comment is called a [directive](directives.md) which
   provides instructions to compiletest on how to build the test. Here we need to
   set the edition for `async` to work (the default is edition 2015).
 - Following that is the source of the test. Try to keep it succinct and to the

src/tests/best-practices.md

@@ -183,6 +183,6 @@ See [LLVM FileCheck guide][FileCheck] for details.
 > Pending concrete advice.
 
 [compiletest]: ./compiletest.md
-[compiletest directives]: ./headers.md
+[compiletest directives]: ./directives.md
 [`run-make`]: ./compiletest.md#run-make-tests
 [FileCheck]: https://llvm.org/docs/CommandGuide/FileCheck.html

src/tests/compiletest.md

@@ -26,7 +26,7 @@ individual and groups of tests.
 Tests are typically organized as a Rust source file with annotations in comments
 before and/or within the test code. These comments serve to direct `compiletest`
 on if or how to run the test, what behavior to expect, and more. See
-[directives](headers.md) and the test suite documentation below for more details
+[directives](directives.md) and the test suite documentation below for more details
 on these annotations.
 
 See the [Adding new tests](adding.md) and [Best practies](best-practiecs.md)
@@ -93,7 +93,7 @@ The tests in [`tests/pretty`] exercise the "pretty-printing" functionality of
 input source into various different formats, such as the Rust source after macro
 expansion.
 
-The pretty-printer tests have several [directives](headers.md) described below.
+The pretty-printer tests have several [directives](directives.md) described below.
 These commands can significantly change the behavior of the test, but the
 default behavior without any commands is to:
 
@@ -242,7 +242,7 @@ fn main() {
 fn b() {}
 ```
 
-The following [directives](headers.md) are available to disable a test based on
+The following [directives](directives.md) are available to disable a test based on
 the debugger currently being used:
 
 - `min-cdb-version: 10.0.18317.1001` — ignores the test if the version of cdb
@@ -575,7 +575,7 @@ known-bug` directive inside the test file.
 ## Building auxiliary crates
 
 It is common that some tests require additional auxiliary crates to be compiled.
-There are multiple [directives](headers.md) to assist with that:
+There are multiple [directives](directives.md) to assist with that:
 
 - `aux-build`
 - `aux-crate`

src/tests/ui.md

@@ -28,7 +28,7 @@ next to the test. See [Output comparison](#output-comparison) for more.
 Additionally, errors and warnings should be annotated with comments within the
 source file. See [Error annotations](#error-annotations) for more.
 
-Compiletest [directives](headers.md) in the form of special comments prefixed
+Compiletest [directives](directives.md) in the form of special comments prefixed
 with `//@` control how the test is compiled and what the expected behavior is.
 
 Tests are expected to fail to compile, since most tests are testing compiler
@@ -78,7 +78,7 @@ There can be multiple stdout/stderr files. The general form is:
 A simple example would be `foo.stderr` next to a `foo.rs` test.
 A more complex example would be `foo.my-revision.polonius.stderr`.
 
-There are several [directives](headers.md) which will change how compiletest
+There are several [directives](directives.md) which will change how compiletest
 will check for output files:
 
 - `stderr-per-bitwidth` — checks separate output files based on the target
@@ -168,7 +168,7 @@ usage example.
 [`main.stderr`]: https://github.com/rust-lang/rust/blob/master/tests/ui/transmute/main.stderr
 
 Besides `normalize-stderr-32bit` and `-64bit`, one may use any target
-information or stage supported by [`ignore-X`](headers.md#ignoring-tests) here
+information or stage supported by [`ignore-X`](directives.md#ignoring-tests) here
 as well (e.g. `normalize-stderr-windows` or simply `normalize-stderr-test` for
 unconditional replacement).
 
@@ -276,7 +276,7 @@ fn main() {
 
 ### `error-pattern`
 
-The `error-pattern` [directive](headers.md) can be used for messages that don't
+The `error-pattern` [directive](directives.md) can be used for messages that don't
 have a specific span.
 
 Let's think about this test:
@@ -366,7 +366,7 @@ By default, a UI test is expected to **generate a compile error** because most
 of the tests are checking for invalid input and error diagnostics. However, you
 can also make UI tests where compilation is expected to succeed, and you can
 even run the resulting program. Just add one of the following
-[directives](headers.md):
+[directives](directives.md):
 
 - Pass directives:
   - `//@ check-pass` — compilation should succeed but skip codegen