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.
Using future annotations, type annotations become strings at runtime and
don't impact performance. This is not possible to do with T.cast though,
because it is a function argument instead of an annotation.
Quote the type argument everywhere in order to have the same effect as
future annotations. This also allows linters to better detect in some
cases that a given import is typing-only.
A bunch of files have several T.TYPE_CHECKING blocks that each do some
things which could just as well be done once, with a single `if`
statement. Make them do so.
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.
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.
In some cases, init variables that accept None as a sentinel and
immediately overwrite with [], are migrated to dataclass field
factories. \o/
Note: dataclasses by default cannot provide eq methods, as they then
become unhashable. In the future we may wish to opt into declaring them
frozen, instead/additionally.
FeatureCheck always immediately sets extra_message to '' if it isn't
explicitly passed, so there is really no point in using None as a
sentinel that is never used.
Names used in init functions are sometimes pointlessly different from
the class instance attributes they are immediately assigned to. They
would make more sense if defined properly.
Currently, if you pass a `[]string`, but the argument expects
`[]number`, then you get a message like `expected list[str] but got
list`. That isn't helpful. With this patch arrays and dictionaries will
both print messages with the types provided.
The inner closure of the typed_kwargs function is already complicated
enough without defining closures in the middle of a loop. Let's just
pass the types_tuple as an argument to both avoid redefining the
function over and over, and also make the whole thing easier to read.
Since these aren't warnings, per se, we don't note every single call
site that has one. And we raise mlog.notice in non-fatal mode to avoid
either:
- being too threatening
- making builds fail with --fatal-meson-warnings
Nevertheless, it is useful to give people a heads-up that there is an
upgrade opportunity, rather than waiting until they upgrade and then
causing projects to begin printing fatal warnings.
mlog can already print location info, and we use this often -- including
for custom feature warnings already. Make this work everywhere, so that
it is feasible to move such custom warnings to globally tracked
Features.
Eli Schwartz
Josh Soref
Xavier Claessens
Charles Brunet
Dylan Baker
Zbigniew Jędrzejewski-Szmek
Peter Lesslie