The "imp" module is deprecated in Python 3.4 and will be removed in
Python 3.12. Use it only if the current Python version is too old to use
the "importlib" module.
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.
* Simplify find_cases
* Improve help text
* Improve YAML-capturing regex
* Use built-in dedenting
* Fix use of built-in dedenting
* Fix use of built-in dedenting for Python 3
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
Prior to this patch, the CircleCI continuous integration environment was
configured to report test failures in a negative light, displaying red
cross-marks and reporting that "some checks were not successful" in
commits and GitHub Pull Requests which included them.
The passing/failing status of tests does not influence their
desirability for Test262. (In practice, engines very commonly fail
newly-contributed tests.)
Although these conflicting interpretations does not technically
interfere with the maintainers' ability to merge new contributions, it
does create confusion for many contributors who interpreted the UI as a
rejection of their work.
In addition, this behavior made it impossible to distinguish between the
benign test failures and disruptive infrastructural problems (e.g. the
crashing of engines).
Reconfigure the continuous integration environment to accept passing and
failing tests equally, and to only report a problem when the Test262
project's testing infrastructure behaves unexpectedly.
The file is derived from the same-named file for SpiderMonkey, therefore I've
kept the MPL license info.
The next commits use this script to generate language tag mappings data.
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.
* Generation: Use Python 3-compatible imports.
* Generation: Use range() instead of xrange().
* Generation: Use list comprehensions instead of map().
* Generation: Explicitly use bytes in the Test class.
* Generation: Run unit tests on Python 3 as well.
the double dot gets only commits not in the left side of the double dot.
The right side assumes HEAD.
This will allow us to fetch the correct list of new or modified files in the current branch.