| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The kind that takes a single argument, not the custom_target version
that takes an array
|
|
Which should take a File or str, but only handles str correctly. Which
mypy would have caught for us, if we just had annotations here.
|
|
It would be too difficult and probably a layering violation to give an
interpreter handle to the inner guts of every dependency. What we can do
instead is let every dependency track:
- the Feature checks it can produce,
- the version attribute for when it was implemented
while leaving the interpreter in charge of actually emitting them.
|
|
The point of a .use() function is because we don't always have the
information we need to use a feature check, so we allow creating the
feature and then storing it for later use. When implementing location
checks, although it is optional, actually using it violated that design.
Move the location out of the init method for FeatureCheck itself. It
remains compatible with all cases of .single_use(), but fix the rest up.
|
|
|
|
|
|
|
|
In one case, we actually specifically want to catch IndexError only. In
the other case, excepting Exception rather than BaseException is quite
fine.
|
|
|
|
|
|
|
|
Use a derived type when passing `subproject` around, so that mypy knows
it's actually a SubProject, not a str. This means that passing anything
other than a handle to the interpreter state's subproject attribute
becomes a type violation, specifically when the order of the *four*
different str arguments is typoed.
|
|
Print the location the warning was encountered, and quote the string
that triggered it. This makes it easier to read what actually happened.
|
|
We do not want anyone touching this entire directory tree, but due to
the way it was implemented, we only checked if its direct parent was a
subproject violation. This generally worked, unless people tried to add
`subprojects/` as an include directory.
Patch this hole. It now provides the same warning any sandbox violation
does (but is not currently an error, just a "will become an error in the
future").
|
|
Forgotten in #8512.
|
|
In commit b30dddd4e5b4ae6e5e1e812085a00a47e3edfcf1, various refactorings
were done, during which a kwarg got accidentally dropped from the
function that determined part of the log message. As a result, a ':'
suddenly appeared in the log message where none should be.
Example expected output:
Checking if "-Werror=shadow with local shadowing" compiles: YES
What actually happened:
Checking if "-Werror=shadow with local shadowing" : compiles: YES
Fixes #9974
|
|
This has never worked for built/found programs, only for script files.
In commit 2fabd4c7dc22373e99fc63823d80083ad30704b8 scripts learned an
attribute stating which subproject they came from. In commit
3990754bf55727ef5593769b48f0a03c6b7a3671 dist scripts learned to run
even from a subproject, and relied on that attribute to know when, in
fact, they came from a subproject.
Unfortunately the original attribute was only set in one half of an
if/else, and the other half returned early with only part of the work
done.
Fixes #9964
|
|
In commit 0deab2ee9efc2ffe9e43f2787611e34656e6a304 we added the ability
to pass a declare_dependency() to any compiler method that accepts
"dependencies", but we never marked the version it is available since.
Fixes #9957
|
|
|
|
Add a new keyword argument to test() and benchmark(), completing the
implementation of the feature.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Because we don't want to pass the Interpreter kwargs into the build
layer. This turned out to be a mega commit, as there's really on elegant
way to make this change in an incremental way. On the nice side, mypy
made this change super easy, as nearly all of the calls to
`CustomTarget` are fully type checked!
It also turns out that we're not handling install_tags in custom_target
correctly, since we're not converting the boolean values into Optional
values!
|
|
This is the right thing to do, using which is wrong.
|
|
This has been completely replaced by typed_kwargs now
|
|
|
|
|
|
The utility function that processes this for both 'variables' and
'uninstalled_variables' accepts a kwarg for the name of the argument,
but then hardcodes 'variables' in the warning message. This is
misleading.
|
|
In commit 06481666f4e74ecef01e59351fc345ab0962d998 this warning got
moved from build.py to the interpreter. Unfortunately it got added to
the wrong function... it is supposed to be part of custom_target and
even mentions this as the feature_name.
Since then, build_always became a KwargInfo and has the deprecated-since
attribute baked into it. But it didn't have the additional message which
it really should have.
Add that message at the same time we remove it from vcs_tag.
|
|
Rather than pointlessly evolving it in the exactly one place which it is
used. It's not clear what the purpose for this was.
|
|
|
|
And one undefined T.cast name in a file that isn't yet mypy-ready
anyway.
|
|
Due to the support for specifying version as files('VERSION'), we need
to internally accept an array, since that is what files() returns.
Before that, we didn't accept arrays, and after that, we don't intend to
accept generic arrays, only arrays as a side effect of files(). So
tighten the typechecking to ensure that that is what we actually get.
|
|
Python inherited a really bad design from C, booleans happen to be ints.
Which is awful, but it's true.
Fixes: #9858
|
|
This is currently allowed, and is used in at least a few projects. It
was not intended to work or documented, but it does and since it is in
use a full deprecation period must be used. A warning has also been
added for values < 0, which have surprising behavior.
|
|
It's no longer required because we don't allow arrays as fallbacks
anymore.
|
|
Which do nothing, and shouldn't be allowed.
|
|
This is much cleaner, and more in line with the way we handle
interpreter objects in modern meson practice
|
|
|
|
This removes the ability to use ConfigurationData as a dict, but
restricting the inputs to `str | int | bool`. This may be a little too
soon for this, and we may want to wait on that part, it's only bee 8
months since we started warning about this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is a layering violation, we're relying on the way the interpreter
handles keyword arguments. Instead, pass them as free variables,
destructuring in the interpreter
|
|
|
|
|
|
|
|
|
|
|
