compare_perf_test.py is now covered with unit tests and public methods are documented in the implementation.
Minor refactoring to better conform to Python conventions:
* classes declared in new style
* proper private method prefix of single underscore
* replacing map with list comprehension where it was clearer
Unit test are executed as part of validation-test.
.gitignore was modified to ignore .coverage and htmlcov artifacts generated by the coverage.py package
The bug reducer makes assumptions about the layout of the swift build directory
that may not be true in non-Ninja builds. Two examples of cmake generators that
would cause problems are VisualStudio and Xcode. I do not have time right now to
add such support, hence the disabling of the test.
rdar://30311943
Currently it supports random bug finding and opt pipeline reduction. At some
point in the future it will support:
1. Reducing of optimizer crasher test cases.
2. Reducing optimizer miscompile test cases.
But those are for another time, this is just a first step. Patches welcome = ).
Check out llvm's bugpoint for inspiration.
It also has a basic test of pass pipeline reduction that is triggered via the
validation testing in lit. One thing to note here is that the tool right now
assumes darwin. This can be fixed in the future.
`utils/line-directive` is used when building Swift (see
`cmake/modules/AddSwift.cmake`), and includes some doctests. In order
to make sure it continues to behave as intended, add its tests to
`validation-test`.
https://bugs.swift.org/browse/SR-237 calls for `build-script` and
`build-script-impl` to be merged. This commit takes another step towards
that goal by moving the logic that finds the path to the `clang` and
`clang++` executables up into Python-land.
Rather than simply moving all of the logic into `utils/build-script`,
this commit moves relevant functions into a new Python module, named
`swift_build_support`. This has several benefits:
- The logic can be tested. Whereas `build-script-impl` needed to be run
in order to verify its behavior, the logic extracted out of it into
`swift_build_support` can be tested in isolation.
- The logic can be split up into several files without polluting the
`utils` directory, which now contains many different files that are
unrelated to `build-script`.
