Previously, split() would split on whitespace, then the if-condition would
remove `#` - interpreting every word in every comment in the file as a
potential valid feature flag. We want splitlines() here.
Partial-line comments were inadvertently "supported" before, because of
this bug. Instead, support them explicitly by chopping off a `#`
character, anything after it, and any whitespace immediately preceding it.
If a specific Python interpreter is used (e.g. by invoking the script with
"/path/to/python run.py") then we should use the same Python interpreter
to execute scripts in subprocesses, not the one from the environment.
The path to the running Python interpreter is given by sys.executable.
The phase field must precede the type field for negative tests
to have a consistent style and be able to parse easier.
Related to the goal of https://github.com/tc39/test262/issues/1997
Added this check to the linting script and updated tests accordingly.
Includes key should use flow notation to be able parsed easier
as suggested in https://github.com/tc39/test262/issues/1997
Added this check to the linting script and updated tests accordingly.
This change is in service of forthcoming tests for the "JSON modules"
language proposal [1]. Verifying the semantics of that proposal requires
modules whose source text is not valid ECMAScript; this change updates
the guidelines for contributing and interpreting tests so that such test
material can be handled consistently.
Differentiating JSON files with a distinct file name suffice will assist
consumers which require special handling of such files (e.g. web
browsers).
Change the pattern used to designate "fixture" files so that it may be
applied to files used for JSON modules.
Increment the project version number to alert consumers of this change
in interpreting instructions.
[1] https://github.com/tc39/proposal-json-modules
Verify that every test file which references a harness file using the
"includes" directive also contains at least one reference to a value
defined in the harness file.
To support this check, extend each harness file with a list of values
which it defines.
The command-line interface to Python's "unittest" module allows users to
run tests by name, e.g.
$ test.py TestLinter.test_foo
If the tests include a period, they cannot be referenced in this way.
Rename the tests to omit the filename extension so that they may be
referenced from the command-line in this way.
Prior to this commit, the tests for the linter partially depended on
project files. This coupling risks churn in the tests: if the needs of
the project change (e.g. a harness file is modified), then the linter
tests would need to be updated. It also made the tests more difficult to
understand because the input was both larger and more complicated than
necessary to exercise the relevant functionality.
Execute the tests in the context of the fixture directory and introduce
minimal support files that serve the same purpose as the corresponding
project files.
The document fragments used by the ECMAScript specification do not
conform to any particular pattern beyond the grammar defined by the URL
standard [1]. Relax the linting rule to enforce a simplified version of
that grammar.
[1] https://url.spec.whatwg.org/#fragment-state
Early errors may result from parsing the source text of a test file, but
they may also result from parsing some other source text as referenced
through the ES2015 module syntax. The latter form of early error is not
necessarily detectable by ECMAScript parsers, however. Because of this,
the label "early" is not sufficiently precise for all Test262 consumers
to correctly interpret all tests.
Update the "phase" name of "early" to "parse" for all those negative
tests that describe errors resulting from parsing of the file's source
text directly. A forthcoming commit will update the remaining tests to
use a "phase" name that is more specific to module resolution.
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.
A recent commit introduced a document that enumerated acceptable values
for the test "features" metadata tag. However, this list was incomplete,
and maintaining it placed extra burden on the project owners.
Restructure the document into a machine-readable format. Add entries for
all previously-omitted values. Add in-line documentation with
recommendations for maintenance of the file. Extend the project's
linting tool to validate tests according to the document's contents.
This script is intended to identify common test file formatting errors
prior to their acceptance into the project. It is designed to support
future extensions for additional validation rules.
Philip Chimento
Csaba Osztrogonác
Mike Pennisi
Rick Waldron
Leo Balter
Gus Caplan
Ms2ger
André Bargull
Mathias Bynens
Valerie R Young