The `__future__` we relied on is now, where the 3 specific things are
all included [since Python 3.0](https://docs.python.org/3/library/__future__.html):
* absolute_import
* print_function
* unicode_literals
* division
These import statements are no-ops and are no longer necessary.
Commit the platform definition and build script work necessary to
cross-compile for arm64_32.
arm64_32 is a variant of AARCH64 that supports an ILP32 architecture.
* [utils] Minor Python tidies in utils/swift-bench.py
* Track the line number where benchmarks are found
* Tidy up the argument parsing code for the default `--compiler` value
* Pull the regex for finding benchmarks out into a top-level constant,
and add comments for improved readability
* Fix Python lint issue
This doesn't change how the function works, just makes it easier to follow:
* Add a docstring that explains how standard deviation is computed
* Use `sample` instead of `l` for the input variable
* Use `math.sqrt` for readability
* Break it down into a couple of intermediate steps for ease of comprehension
Plus a nicer error message in the case where you try to get the standard deviation of an empty list (previously you got a not-completely obvious ZeroDivisionError).
Prior to this commit:
```
$ pylint utils/swift-bench.py 2>&1 | grep '(no-member)'
E:360,12: Instance of 'Test' has no 'results' member (no-member)
E:364,18: Instance of 'Test' has no 'output' member (no-member)
$
```
After this commit:
```
$ pylint utils/swift-bench.py 2>&1 | grep '(no-member)'
$
```
* E101: indentation contains mixed spaces and tabs
* E111: indentation is not a multiple of four
* E128: continuation line under-indented for visual indent
* E302: expected 2 blank lines, found 1
* W191: indentation contains tabs
The repo contains roughly 80 Python scripts. "snake_case" naming is used for
local variables in all those scripts. This is the form recommended by the PEP 8
naming recommendations (Python Software Foundation) and typically associated
with idiomatic Python code.
However, in nine of the 80 scripts there were at least one instance of
"camelCase" naming prior to this commit.
This commit improves consistency in the Python code base by making sure that
these nine remaining files follow the variable naming convention used for
Python code in the project.
References:
* PEP 8: https://www.python.org/dev/peps/pep-0008/
* pep8-naming: https://pypi.python.org/pypi/pep8-naming
Fixes:
* multiple statements on one line (colon) (E701)
* missing whitespace around arithmetic operator (E226)
* missing whitespace around operator (E225)
* closing bracket does not match visual indentation (E124)
* blank line contains whitespace (W293)
* continuation line missing indentation or outdented (E122)
* continuation line over-indented for hanging indent (E126)
* missing expected blank line (E301)
* trailing whitespace (W291)
* unexpected spaces around keyword / parameter equals (E251)
* whitespace after '(', '[' or '{' (E201)
* whitespace before ')', ']' or '}' (E202)
* whitespace before ',' or ':' (E203)
This patch adds powerpc64le Linux support. While the patch also adds
the matching powerpc64 bits, there are endian issues that need to be
sorted out.
The PowerPC LLVM changes for the swift ABI (eg returning three element
non-homogeneous aggregates) are still in the works, but a simple LLVM
fix to allow those aggregates results in swift passing all but 8
test cases.
Rather than using `f = open(path).read()`, which leaves the file open
for an indeterminate period of time, switch to the `with open(path) as f`
idiom, which ensures the file is always closed correctly.
In Python 3, 'print' was changed from a statement to a function. Using
the __future__ module allows scripts to use print function whether
running with Python 2.6+ or Python 3.x. This commit changes as many
instances of print as I could find to use the print function and the
__future__ module.
This reflects the fact that the attribute's only for compiler-internal use, and isn't really equivalent to C's asm attribute, since it doesn't change the calling convention to be C-compatible.
Currently it's in early development stage, and is not intented for
massive usage.
Feature requests can be posted here:
<rdar://problem/18072938>
Swift SVN r21530
