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.
Some of our unit tests now have non-numeric block IDs, like
"bb1a". While that may not be ideal, it seems harmless to tweak this
regex to handle those cases.
LLVM r356789 changed the format of textual IR to print nameless
blocks with labels instead of comments with "; <label>". Adjust Swift
tests to match. I also updated the utils/viewcfg script to match.
* 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)
Fixes:
* blank line at end of file
* closing bracket does not match indentation of opening bracket's line
* continuation line over-indented for hanging indent
* continuation line over-indented for visual indent
* continuation line unaligned for hanging indent
* inline comment should start with '# '
* missing whitespace around arithmetic operator
* missing whitespace around bitwise or shift operator
* multiple imports on one line
* multiple spaces after ':'
* multiple spaces after operator
In order to prevent the Python interpreter from running code that is
meant to be executed directly, the convention is to check the context
in which the code is being interpreted.
Add a check for the context stored in the `__name__` variable, and only
execute the viewcfg script if it is being run as a command-line
script (that is, `__main__`).
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.
It is useful if you have the SIL already in a file (instead of calling viewCFG() while running the compiler in lldb).
Especially useful for vim users: see the comment in the script on how to add commands to view the CFG from inside vim.
Swift SVN r30186
Meghana Gupta
Daniel Duan
Meghana Gupta
Andrew Trick
Michael Gottesman
Bob Wilson
Erik Eckstein
Hugh Bellamy
practicalswift
Brian Gesiak
Zach Panzarino
Alex Chan