[NFC][Py Reformat] Reformat python files in clang and clang-tools-extra

This is an ongoing series of commits that are reformatting our
Python code.

Reformatting is done with `black`.

If you end up

[NFC][Py Reformat] Reformat python files in clang and clang-tools-extra

This is an ongoing series of commits that are reformatting our
Python code.

Reformatting is done with `black`.

If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.

If you run into any problems, post to discourse about it and
we will try to help.

RFC Thread below:

https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style

Reviewed By: MatzeB

Differential Revision: https://reviews.llvm.org/D150761

show more ...

Portable Python script across Python version

In Python3, dict.items, dict.keys, dict.values, zip, map and filter no longer return lists, they create generator instead.

The portability patch consist

Portable Python script across Python version

In Python3, dict.items, dict.keys, dict.values, zip, map and filter no longer return lists, they create generator instead.

The portability patch consists in forcing an extra `list` call if the result is actually used as a list.
`map` are replaced by list comprehension and `filter` by filtered list comprehension.

Differential Revision: https://reviews.llvm.org/D55197

llvm-svn: 349501

show more ...

Portable Python script across Python version

In Python2, division between integer yields an integer, while it yields a float in Python3.
Use a combination of from __future__ import division and // o

Portable Python script across Python version

In Python2, division between integer yields an integer, while it yields a float in Python3.
Use a combination of from __future__ import division and // operator to get a portable behavior.

Differential Revision: https://reviews.llvm.org/D55204

llvm-svn: 349455

show more ...

Portable Python script across Python version

Using from __future__ import print_function it is possible to have a compatible behavior of `print(...)` across Python version.

Differential Revision: h

Portable Python script across Python version

Using from __future__ import print_function it is possible to have a compatible behavior of `print(...)` across Python version.

Differential Revision: https://reviews.llvm.org/D55213

llvm-svn: 349454

show more ...

Portable Python script across Python version

Replace `xrange(...)` by either `range(...)` or `list(range(...))` depending on the context.

Differential Revision: https://reviews.llvm.org/D55193

llv

Portable Python script across Python version

Replace `xrange(...)` by either `range(...)` or `list(range(...))` depending on the context.

Differential Revision: https://reviews.llvm.org/D55193

llvm-svn: 349448

show more ...

Portable Python script across Python version

Python3 does not support type destructuring in function parameters.

Differential Revision: https://reviews.llvm.org/D55198

llvm-svn: 348129

Portable Python script across version

Have all classes derive from object: that's implicitly the default in Python3,
it needs to be done explicilty in Python2.

Differential Revision: https://review

Portable Python script across version

Have all classes derive from object: that's implicitly the default in Python3,
it needs to be done explicilty in Python2.

Differential Revision: https://reviews.llvm.org/D55121

llvm-svn: 348127

show more ...

Portable Python script across Python version

Python2 supports the two following equivalent construct

raise ExceptionType, exception_value
and
raise ExceptionType(exception_value)

Only the later

Portable Python script across Python version

Python2 supports the two following equivalent construct

raise ExceptionType, exception_value
and
raise ExceptionType(exception_value)

Only the later is supported by Python3.

Differential Revision: https://reviews.llvm.org/D55195

llvm-svn: 348126

show more ...

Fix invalid test generation by utils/ABITest/ABITestGen.py when the same enum is generated more than once.

When generating records/unions, the same enum type may be generated more
than once (with di

Fix invalid test generation by utils/ABITest/ABITestGen.py when the same enum is generated more than once.

When generating records/unions, the same enum type may be generated more
than once (with different names). In these cases, the name of the enum
values are not sufficiently unique to prevent multiple declarations. E.g:
typedef enum T3 { enum0val0 } T3;
typedef T3 T2[3];
typedef enum T4 { enum0val0 } T4;
typedef union T1 { T2 field0; T4 field1; char field2; } T1;

Added a unique suffix to enum values so that multiple identical enum types do
not use the same enum value names.

One example of this bug is produced by:
ABITestGen.py --no-unsigned --no-vector --no-complex --no-bool \
--max-args 0 --max-record-depth 1 -o inputs/test.9921.a.c \
-T inputs/test.9921.b.c -D inputs/test.9921.driver.c \
--min=9921 --count=1

llvm-svn: 216166

show more ...

utils/ABITest: Factor out type naming code slightly.

llvm-svn: 114867

Implement promotion for enumeration types.

WHAT!?!

It turns out that Type::isPromotableIntegerType() was not considering
enumeration types to be promotable, so we would never do the
promotion despi

Implement promotion for enumeration types.

WHAT!?!

It turns out that Type::isPromotableIntegerType() was not considering
enumeration types to be promotable, so we would never do the
promotion despite having properly computed the promotion type when the
enum was defined. Various operations on values of enum type just
"worked" because we could still compute the integer rank of an enum
type; the oddity, however, is that operations such as "add an enum and
an unsigned" would often have an enum result type (!). The bug
actually showed up as a spurious -Wformat diagnostic
(<rdar://problem/7595366>), but in theory it could cause miscompiles.

In this commit:
- Enum types with a promotion type of "int" or "unsigned int" are
promotable.
- Tweaked the computation of promotable types for enums
- For all of the ABIs, treat enum types the same way as their
underlying types (*not* their promotion types) for argument passing
and return values
- Extend the ABI tester with support for enumeration types

llvm-svn: 95117

show more ...

Add to the house of cards that is ABITestGen.
- Support generating structures with bit-fields.

llvm-svn: 71192

Note some more things to integrate into ABITest

llvm-svn: 64846

ABITestGen: Add generation of vector types.

llvm-svn: 63024

Add simple make based harness for running ABI tests.

llvm-svn: 62916

Add utils/ABITest, my ABI test generation tool.
- Mostly written as an entertaining exercise in enumerating large or
(countably, naturally) infinite sets. But hey, its useful too!

- Idea is to

Add utils/ABITest, my ABI test generation tool.
- Mostly written as an entertaining exercise in enumerating large or
(countably, naturally) infinite sets. But hey, its useful too!

- Idea is to number all C-types so that the N-th type can quickly be
computed, with a good deal of flexibility about what types to
include, and taking some care so that the (N+1)-th type is
interestingly different from the N-th type. For example, using the
default generator, the 1,000,000-th function type is:
--
typedef _Complex int T0;
typedef char T1 __attribute__ ((vector_size (4)));
typedef int T2 __attribute__ ((vector_size (4)));
T2 fn1000000(T0 arg0, signed long long arg1, T1 arg2, T0 arg3);
--
and the 1,000,001-th type is:
--
typedef _Complex char T0;
typedef _Complex char T2;
typedef struct T1 { T2 field0; T2 field1; T2 field2; } T1;
typedef struct T3 { } T3;
unsigned short fn1000001(T0 arg0, T1 arg1, T3 arg2);
--

Computing the 10^1600-th type takes a little less than 1s. :)

llvm-svn: 62253

show more ...