| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
This caught a couple of cases of us doing:
```python
for i in range(len(x)):
v = x[i]
```
which are places to use enumerate instead.
It also caught a couple of cases of:
```python
assert len(x) == len(y)
for i in range(len(x)):
xv = x[i]
yv = y[i]
```
Which should instead be using zip()
```python
for xv, yv in zip(x, y):
...
```
|
|
We have a lot of these. Some of them are harmless, if unidiomatic, such
as `if (condition)`, others are potentially dangerous `assert(...)`, as
`assert(condtion)` works as expected, but `assert(condition, message)`
will result in an assertion that never triggers, as what you're actually
asserting is `bool(tuple[2])`, which will always be true.
|
|
Which is really useful for catching parens used with keywords like
assert. Don't use parens with assert, it's bad.
|
|
This didn't actually catch what it's supposed to, which is cases of:
```python
for x in dict.keys():
y = dict[x]
```
But it did catch one unnecessary use of keys(), and one case where we
were doing something in an inefficient way. I've rewritten:
```python
if name.value in [x.value for x in self.kwargs.keys() if isinstance(x, IdNode)]:
```
as
``python
if any((isinstance(x, IdNode) and name.value == x.value) for x in self.kwargs):
```
Which avoids doing two iterations, one to build the list, and a
second to do a search for name.value in said list, which does a single
short circuiting walk, as any returns as soon as one check returns True.
|
|
This finds things like
```python
if not x == 1:
```
which should be
```python
if x != 1:
```
|
|
Make EnvironmentVariablesObject a holder
|
|
Handle aarch64_be as a cpu family
|
|
* Make assignment a statement in Syntax
force to change line 709 to something kind of non sensical
* Applied code review changes
|
|
We use distutils, not setuptools, for probing information.
|
|
This is more consistent with other Holder classes
|
|
|
|
Currently, EnvironmentVariablesObject is a strange
holder-that's-not-a-holder. This has implicaitons for things that expect
to get an EnvironmentVariables object, as we can't automatically
unholder it, and instead have to to manually do so. Now we can
automatically unholder it, which makes everything much nicer.
|
|
|
|
Since the convertor has been added env, we are now only going to be an
EnvironmentVariables object, nothing else.
|
|
This does the conversion to an EnvironmentVariables, so that the
receiver always gets a EnvironmentVariables object and not a list, dict,
or string
|
|
Let's start moving the validation out of the interpreter object
|
|
|
|
Which is useful as we move the validation out of the the
EnvironmentVariablesObject
|
|
|
|
|
|
|
|
There is a unit test using it and now fails because the warning about
unknown kwarg became fatal.
|
|
|
|
|
|
Fixes #9191
|
|
This seems like an oversight, that we'd replace ppc with ppc64 on AIX
for the cpu_family, but not for the specific cpu.
|
|
Same thing, but for the more specific cases
|
|
This should help prevent regressions.
|
|
These are just annotations in code that I'm working for this series
|
|
`ninja -l` accepts a double. We should do the same.
Bug: https://bugs.gentoo.org/810655
|
|
Otherwise, if these environment variables already exist, they will
override values we set for the developer environment.
|
|
Validate default values for KwargInfo
|
|
|
|
Because mypy doesn't like the type alias.
|
|
|
|
Because currently you can write something like:
```python
KwargInfo('capture', bool)
```
Which proclaims "this must be bool", but the default is then not valid.
|
|
The correct way to mark these is `KwargInfo(..., (T, type(None)))`.
There's also a few cases of `(T, None)` which is invalid, as `None`
isn't a type
|
|
There was a copy-n-paste error here, and it was benchmark instead.
|
|
|
|
|
|
This is quite valuable for enum-like inputs, where only a certain set
of values is allowed.
|
|
Exception is thrown when dependency name is empty and when its
'include_type' differs from the default one.
Regression from b6d754a40c.
|
|
This is useful information for solving the OS bootstrapping problem.
Give it some visibility.
Also, I don't want to forget where I found any of these. :D
ref. #2335
|
|
The sysconfig paths are, by default, correct for every OS -- they are
supposed to follow the scheme that python knows about per default.
For some reason, this overrode the scheme to posix_prefix, which is the
default for posix OSes like linux and macOS, but wrong on Windows.
Simply deleting this entirely makes everything that used to work, still
work, and a couple new things start working.
|
|
|
|
The tool needs to run the preprocessor (but does not actually produce
compiled outputs), and meanwhile ignores lots of flags it doesn't think
it needs. In the case of -D_FORTIFY_SOURCE=... this is only valid if -O
is there too, but otherwise spits out confusing warnings.
The warnings are spurious and can be safely ignored, but in this case
let's go the extra mile and fix g-ir-scanner's upstream bug by removing
the fortify flag first.
Fixes #9161
|
|
It should apply to the *next* stable release.
Reported-by: Tristan Partin <tristan@partin.io>
|
|
It should build the fallback subprject with default_library=static and
override the dependency for both static=True and static kwarg not given.
Fixes: #8050.
|
