Enforce use of `throw` stmt in early error tests

Previously, test consumers were encouraged to insert a `throw` statement
as the first statement of tests for early errors. This recommendation
made tests harder to consume, and as an optional transformation,
consumers may have ignored it or simply been unaware it was made. By
explicitly including such a `throw` statement, the tests become more
literal, making them easier to consume and more transparent in their
expectations.

Document expectation for all tests for early errors to include an
explicit `throw` statement. Extend linting script to verify that
contributors are automatically notified of violations and to ensure that
future contributions satisfy this expectation.

1 files changed, 1 insertions, 10 deletions

diff --git a/INTERPRETING.md b/INTERPRETING.md
index 4f837b78d..6c78fa67c 100644
--- a/INTERPRETING.md
+++ b/INTERPRETING.md
@@ -147,8 +147,7 @@ attribute is a YAML dictonary with two keys:
 
 - `phase` - the stage of the test interpretation process that the error is
   expected to be produced; either "early" (meaning, "prior to evaluation") or
-  "runtime" (meaning, "during evaluation"); in the case of "early", additional
-  test transformation may be required--see below
+  "runtime" (meaning, "during evaluation")
 - `type` - the name of the constructor of the expected error
 
 If a test configured with the `negative` attribute completes without throwing
@@ -167,14 +166,6 @@ negative:
 unresolvable;
 ```
 
-Consumers are free to assert the "early" phase as they see fit.
-
-For example, it is possible to insert a `throw` statement with a unique error
-type at the beginning of the test file. In this case, the statement should be
-inserted *after* the directive desribed in the section titled "Strict Mode"
-(where appropriate), though it must *not* be inserted for tests containing the
-"raw" flag.
-
 ### `includes`
 
 One or more files whose content must be evaluated in the test realm's global