When projects do not specify a minimum meson version, we used to avoid
giving them the benefit of the Feature checks framework. Instead:
- warn for features that were added after the most recent semver bump,
since they aren't portable to the range of versions people might use
these days
- warn for features that were deprecated before the upcoming semver
bump, i.e. all deprecated features, since they aren't portable to
upcoming semver-compatible versions people might be imminently upgrading
to
This reverts commit 9f02d0a3e5.
It turns out that this does introduce a behavioral change in existing
users of ConfigurationData, which it wasn't supposed to (it was supposed
to preserve behavior there, and add a new *warning* for
EnvironmentVariables).
This breaks projects such as pulseaudio, libvirt, and probably more.
Roll back the change and try again after 1.5.0 is released.
Fixes: #13372
Only Environment and ConfigurationData are mutable. However, only
ConfigurationData becomes immutable after first use which is
inconsistent.
This deprecates modification after first use of Environment object and
clarify documentation.
This replaces all of the Apache blurbs at the start of each file with an
`# SPDX-License-Identifier: Apache-2.0` string. It also fixes existing
uses to be consistent in capitalization, and to be placed above any
copyright notices.
This removes nearly 3000 lines of boilerplate from the project (only
python files), which no developer cares to look at.
SPDX is in common use, particularly in the Linux kernel, and is the
recommended format for Meson's own `project(license: )` field
We try to backtrack through the filesystem to find the correct directory
to build in, and suggest this as a possible diagnostic. However, our
current heuristic relies on parsing the raw file with string matching to
see if it starts with `project(`, and this may or may not actually work.
Instead, do a bit of recursion and parse each candidate with mparser,
then check if the first node of *that* file is a project() function.
This makes us resilient to a common case: where the root meson.build is
entirely valid, but, the first line is a comment containing e.g. SPDX
license headers and a simple string comparison simply does not cut it.
Fixes the bad error message from #12441, which was supposed to provide
more guidance but did not.
Performed using https://github.com/ilevkivskyi/com2ann
This has no actual effect on the codebase as type checkers (still)
support both and negligible effect on runtime performance since
__future__ annotations ameliorates that. Technically, the bytecode would
be bigger for non function-local annotations, of which we have many
either way.
So if it doesn't really matter, why do a large-scale refactor? Simple:
because people keep wanting to, but it's getting nickle-and-dimed. If
we're going to do this we might as well do it consistently in one shot,
using tooling that guarantees repeatability and correctness.
Repeat with:
```
com2ann mesonbuild/
```
When performing isinstance checks, an identity comparison is
automatically done, but we don't use isinstance here because we need
strict identity equality *without allowing subtypes*.
Comparing type() == type() is a value comparison, but could produce
effectively the same results as an identity comparison, usually, despite
being semantically off. pycodestyle learned to detect this and warn you
to do strict identity comparison.
We always expect the args parameter in the wrapped function to
eventually receive a tuple due to reasons. But in one specific optargs
condition we passed it along without any fixup at all.
This detects cases where module A imports a function from B, and C
imports that same function from A instead of B. It's not part of the API
contract of A, and causes innocent refactoring to break things.
This is useful for totally terrible stuff that we really dislike, but
for some reason we are afraid to just use `mlog.deprecation()` and
unconditionally tell people so.
Apparently this is because it is totally absolutely vital that, when
telling people something is so broken they should never ever ever use it
no matter what, ever... we can't actually tell them that unless they
bump the minimum version of Meson, because that's our standard way of
introducing a **version number** to tell them when we first started
warning about this.
Sigh. We really want to warn people if they are doing totally broken
stuff no matter what version of Meson they support, because it's not
like fixing the thing that never worked is going to suddenly break old
versions of meson.
So. Here's some new functionality that always warns you, but also tells
you when we started warning.
During evaluation of codeblocks, we start off with an iteration of
nodes, and then while evaluating them we may update the global
self.current_node context. When catching and formatting errors, we
didn't take into account that the node might be updated from the
original top-level iteration.
Switch to formatting errors using self.current_node instead, to ensure
we can point at the likely most-accurate actual cause of an error.
Also update the current node in a few more places, so that function
calls always see the function call as the current node, even if the most
recently parsed node was an argument to the function call.
Fixes#11643
In commit eaf365cb3e we explicitly sorted
them for neatness, with the rationale that we were restoring intentional
behavior and we only need a set for stylistic purposes.
This actually wasn't true, because we never sorted them to begin with
(we did sort the version numbers), but sorting them is fine. The bigger
issue is that we actually used a set to avoid printing the same feature
type multiple times. Now we do print them multiple times -- because each
registered feature includes the unique node.
Fix this by using both sorted and a set.
Fix tests that should in retrospect have flagged this as an issue, but
were added later on in the same series to check something else entirely,
happen to cover this too, and were presumably copied directly from
stdout as-is...
If we add new kwargs to a function invoked on the first line, we also
need to validate the meson_version before erroring out due to unknown
kwargs. Even if the AST was successfully built.
Amusingly, we also get to improve the error message a bit. By passing
the AST node instead of an interpreter node, we get not just line
numbers, but also column offsets of the issueful meson_version. That
broke the stdout of another failing test; adapt it.
If the meson.build file is sufficiently "broken", even attempting to lex
and parse it will totally fail, and we error out without getting the
opportunity to evalaute the project() function. This can fairly easily
happen if we add new grammar to the syntax, which old versions of meson
cannot understand. Setting a minimum meson_version doesn't help, because
people with a too-old version of meson get parser errors instead of
advice about upgrading meson.
Examples of this include adding dict support to meson.
There are two general approaches to solving this issue, one of which
projects are empowered to do:
- refactor the project to place too-new syntax in a subdir() loaded
build file, so the root file can be interpreted
- teach meson to catch errors in building the initial AST, and just load
enough of the AST to check for meson_version advice
This implements the latter, allowing to future-proof the build
grammar.
Currently in our deprecated/new feature printing we carefully sort all
of the values, then put them in a set to print them. Which unsorts them.
I'm assuming this was done because a set looks nice when printed (which
is true). Let's keep the formatting, but print them in a stable order.
Some functions cannot be fully type checked, because our API allows
fully arbitrary kwargs and treats them as data to pass through to the
underlying feature. For example, hotdoc command line arguments.
This change allows us to type check some kwargs with known types and
possibly required status, and make their values consistent(ly defaultable),
while preserving the optional nature of the additional kwargs.
This can be triggered if someone tries to call a non-ID. The example
reproducer was:
```
if (var = dependency(...)).found()
```
This produced a traceback ending in
```
raise InvalidArguments(f'Variable "{object_name}" is not callable.')
UnboundLocalError: local variable 'object_name' referenced before assignment
```
After this commit, the error is reported as:
```
ERROR: AssignmentNode is not callable.
```
Given a kwarg value that is itself a dict/list, we would only check if
the since_values was present within that container. If the since_values
is itself the dict or list type, then we aren't looking for recursive
structures, we just want to know when the function began to accept that
type.
This is relevant in cases where a function accepted a dict, and at one
point began accepting a list (of strings in the form 'key=value'), or
vice versa.
"targetting" is verb-derived adjective, which sort-of-works here, but
makes the whole sentence awkward, because there's no verb. Let's just
use present simple.
"tried to use" implies that the attempt was not successful, i.e. that meson
ignored the feature. But that is not what happens, apart from the warning the
feature works just fine. The new message is also shorter ;)
+ Extend the parser to recognize the multiline f-strings, which the
documentation already implies will work.
The syntax is like:
```
x = 'hello'
y = 'world'
msg = f'''This is a multiline string.
Sending a message: '@x@ @y@'
'''
```
which produces:
```
This is a multiline string.
Sending a message: 'hello world'
```
+ Added some f-string tests cases to "62 string arithmetic" to exercise
the new behavior.
These are only used for type checking, so don't bother importing them at
runtime.
Generally add future annotations at the same time, to make sure that
existing uses of these imports don't need to be quoted.
Dylan Baker
Eli Schwartz
Eli Schwartz
Jussi Pakkanen
Xavier Claessens
Charles Brunet
Tristan Partin
JCWasmx86
Josh Soref
Zbigniew Jędrzejewski-Szmek
Peter Lesslie