This does not convert the build side, or remove any of the checking it
does. We still need that for other callers of custom target. What we'll
do for those is add an internal interface that defaults things, then
we'll be able to have those callers do their own validation, and the
CustomTarget validation machinary can be removed.
Fixes#9096
This will happen as we transition from doing the conversion in the
function body to using the KwargInfo to make that change. If we get one
just return it.
In the comparison methods of Target. There are several problems with the
old implementation:
1. It's not idiomatic
2. It can match on things that It shouldn't (like a Compiler, which has
a `get_id() -> str` method, but not one that we should compare with
Targets
3. It confuses mypy, which doesn't handle hasattr
It would probably be better if CommandBase had an initializer so it
could set the depend_files and dependencies attributes itself, but this
will make mypy happier.
I've used any because it needs to be infinitely recursive, something
that we simply can't model. But basically until it goes into validator
we have no way of knowing what's going on, since one can write code
like:
```python
KwargInfo[str]('arg', object, validator=_some_very_complex_logic_to_get_specific_string)
```
As such, we can't assume that validator is receiving a type _T, it could
be anything.
This reverts commit 5fcb0e6525.
The commit is a massive change that should have been split in
separate pieces, and it also removes a few features:
* in verbose mode, subtests are not printed as they happen
* in non-verbose mode the progress report does not include the
number of subtests that have been run
* in non-parallel mode, output is batched rather than printed as
it happens
Furthermore, none of these changes are not documented in the release
notes. Revert so that each proposal can be tested, evaluated and
documented individually.
Hardcoding the name is fragile, and enabling it based on the existence of
/etc/debian_version (as the is_debianlike helper does) will result in
incorrect paths if the Python binary is not provided by Debian.
Using the deb_system distuils scheme instead makes sure we use the
install path from the current interpreter, which Debian could change
between releases, and gives us the correct value on Python installations
that are not provided by Debian (eg. deadsnakes, Github Action Python,
etc.)
Do notice, though, that there is still no guarantee that these are the
correct paths, as they assume all schemes paths have the install prefix
as a base, see #9284.
Signed-off-by: Filipe Laíns <lains@riseup.net>
Another commit in my quest to rid InterpreterBase from all higher
level object processing logic.
Additionally, there is a a logic change here, since `str.join` now
uses varargs and can now accept more than one argument (and supports
list flattening).
This change set aims to fix various "issues" seen with the current
implementation. The changes can be summarized with the following list:
* Replace emojis and spinners with multiline status displaying the name
and running time of each currently running test.
* The test output (especially in verbose mode or when multiple failing
tests' output gets printed out) can get confusing. Try to make the
output easier to read and grasp. Most notable change here is the
addition of the test number to the beginning of each printed line.
* Print exit details (i.e. exit code) of the test in verbose mode.
* Try to make the verbose "live" output from tests to match the look and
feel of otherwise produced (verbose) test output.
Clippy is a compiler wrapper for rust that provides an extra layer of
linting. It's quite popular, but unfortunately doesn't provide the
output of the compiler that it's wrapping in it's output, so we don't
detect that clippy is rustc. This small patch adds a new compiler class
(that is the Rustc class with a different id) and the necessary logic to
detect that clippy is in fact rustc)
Fixes: #8767
Currently this implements 3 warning levels, 1 and 2 are just the
"default" set by rustc, 3, is "everything is a warning", and 0 is
"nothign is a warning".
This should be done in all cases of language_stdlib_only_link_flags, but
I don't have access to all of the compilers to test it.
This is required in cases where object files created by gfortran are
linked using another compiler with a differen default search path, such
as gfortran and clang together.
This patch adds a new meson built-in option for cython, allowing it to
target C++ instead of C as the intermediate language. This can, of
course, be done on a per-target basis using the `override_options`
keyword argument, or for the entire project in the project function.
There are some things in this patch that are less than ideal. One of
them is that we have to add compilers in the build layer, but there
isn't a better place to do it because of per target override_options.
There's also some design differences between Meson and setuptools, in
that Meson only allows options on a per-target rather than a per-file
granularity.
Fixes#9015
I ran into one of these from LGTM, and it would be nice if pylint could
warn me as part of my local development process instead of waiting for
the CI to tell me.
Dylan Baker
Xavier Claessens
makise-homura
Paolo Bonzini
Filipe Laíns
Eli Schwartz
Alan Coopersmith
Daniel Mensinger
Hemmo Nieminen