Commit Graph

7 Commits

Author SHA1 Message Date
Harlan Haskins
b1d6e17d9f [coverage] Added coverage_mode definitions in validation test and Unit test lit.site.cfg.in 2016-01-28 15:31:03 -08:00
Zach Panzarino
e3a4147ac9 Update copyright date 2015-12-31 23:28:40 +00:00
Brian Gesiak
a45a4260d8 [python] Use PEP-0008 compliant code headers
Running the Python style guide checker
[`pep8`](https://pypi.python.org/pypi/pep8) on the Python code headers
in this repository results in the following error being emitted:

    $ pep8 utils/build-script
    utils/build-script:1:1: E265 block comment should start with '# '
    utils/build-script:3:1: E266 too many leading '#' for block comment
    utils/build-script:5:1: E266 too many leading '#' for block comment
    utils/build-script:6:1: E266 too many leading '#' for block comment
    utils/build-script:8:1: E266 too many leading '#' for block comment
    utils/build-script:9:1: E266 too many leading '#' for block comment
    utils/build-script:11:1: E265 block comment should start with '# '
    utils/build-script:11:80: E501 line too long (80 > 79 characters)

The problem is that the code header used in most Python files in the
repository:

1. Do not place a space in between `#` and the rest of the comment.
2. Contains some lines that just barely exceed the recommend length
   limit.

In addition, not all code headers in the repository follow the same
template.

This commit moves all Python code headers to the following template:

    # subfolder/file_name.py - Very brief description -*- python -*--
    #
    # This source file is part of the Swift.org open source project
    #
    # Copyright (c) 2014 - 2015 Apple Inc. and the Swift project authors
    # Licensed under Apache License v2.0 with Runtime Library Exception
    #
    # See http://swift.org/LICENSE.txt for license information
    # See http://swift.org/CONTRIBUTORS.txt for the list of Swift project authors
    #
    # -----------------------------------------------------------------------------
    #
    # This file contains stuff that I am describing here in the header and will
    # be sure to keep up to date.
    #
    # ----------------------------------------------------------------------------
2015-12-24 11:35:53 -05:00
Jordan Rose
d90e01f0ce [test] Throw away logic for detecting LLVM build directories.
We were never in this situation. For future reference, there are
two ways to use lit manually:

% lit.py $BUILD/swift*/test-macosx-x86_64/$TESTS
% lit.py --param swift_site_config=$BUILD/swift*/test-macosx-x86_64/lit.site.cfg test/$TESTS

The latter is more verbose, but lets you point at real test files in the
source directory instead of pretending they exist in the build directory.
There are probably still further improvements to be made here.

(P.S. I suggest using -sv if running lit from the command line.)

Swift SVN r31647
2015-09-03 00:51:35 +00:00
Jordan Rose
99febda07f Simplify the CMake-generated lit.py invocation.
Now it's down to what I use myself, plus the --xunit-xml-output flag.
I also threw out a fair number of options we weren't using.

Swift SVN r31646
2015-09-03 00:51:25 +00:00
Doug Gregor
68125d5275 Update lit configuration per LLVM r188108.
Swift SVN r7145
2013-08-12 14:18:26 +00:00
John McCall
eaae8b50d1 Add a unit test suite, including a test for
swift_getGenericMetadata.  Mostly ripped off clang's
support for same.  I did not feel confident in pulling
over the CMake equivalents, so someone else will need to.

Swift SVN r2982
2012-10-11 06:51:47 +00:00