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.
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").
In commit b30dddd4e5, 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 2fabd4c7dc scripts learned an
attribute stating which subproject they came from. In commit
3990754bf5 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 0deab2ee9e 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
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!
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 06481666f4 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.
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.
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.
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
Fixes a bug where the subproject version was not validated
when the subproject had already been processed.
The bug would cause inconsistent build results if the subproject was
referenced more than once (diamond) with conflicting version requirements.
In commit c239ce31f5 support was added to
these functions to accept various non-string types.
Despite the commit/PR documenting that only add_install_script is
permitted to accept built files, the actual check parameter was set, for
all three, to "True" (so the function was never invoked with False at
all). This meant that actually attempting to use the allowed types would
fail at postconf or dist, with python tracebacks in the former case and
"Failed to run dist script" in the latter case.
This was partially ameliorated in commit
6c5bfd4c24 which added typed_pos_args, but
unfortunately those typed_pos_args were all over the place.
For postconf:
- They banned external programs as additional args (which should be allowed)
- They banned built executables (good)
- They allowed custom targets as additional args (bad)
For dist:
- they allowed external programs (good)
- they allowed built executables, but only as the first argument (bad, also ???)
- they allowed custom targets, but only as additional arguments (bad, also ???)
Fix this all to only allow the same argument types for both the script
argument and the script-args arguments. That type is known at configure
time and restricted to source files, configured files, and found
programs.
Xavier Claessens
Christian Wendt
Eli Schwartz
Jussi Pakkanen
Paolo Bonzini
Dylan Baker
Øyvind Aarrestad Aakre