Fix a TODO comment about moving to asyncio.run, now that we use
sufficiently new python to do it.
Note that we create an event loop for Windows using the new python
defaults, but in a completely different part of the code from where we
need to use it. Since asyncio.run creates the loop on its own, we need
to set the default policy instead -- which we probably should have done
all along.
In https://bugs.python.org/issue42392 this stopped implicitly creating
an event loop if none exists. We created it before running _run_tests(),
so it would auto-create an event loop and set the default, which means
we cannot create one explicitly on our own schedule or we end up with
two of them.
Delay this until we actually start the logger. This happens inside the
actual testsuite loop, so it finds the running loop and doesn't create a
new one, even on python <3.10.
Useful for running the testsuite with this environment variable and
catching obscure issues. Just like with the encoding warning later down,
we have to do this inside meson itself, not externally injected.
Generated objects can already be passed in the "objects" keyword argument
as long as you go through an extract_objects() indirection. Allow the
same even directly, since that is more intuitive than having to add them
to "sources".
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
It's probably not useful to spam the user with warnings that old
versions of software may not behave correctly when the first warning was
perfectly valid.
There are lots of warnings that become fatal, that are simply unfixable
by the end user. Things like using old versions of software (because
they're using some kind of LTS release), warnings about compilers not
supporting certain kinds of checks, or standards being upgraded due to
skipped implementations (MSVC has c++98 and c++14, but not c++11). None
of these should be fatal, they're informative, and too important to
reduce to notices, but not important enough to stop meson if they're
printed.
We need this outside the constructor for the ParseException class, so
let's pull it out. mlog seemed like a good place since it's a text
formatting function, and has no dependencies.
enum comparisons are ultimately ints, so they're faster, plus they're
exhaustive, so mypy can statically determine that we've passed a valid
value rather than via an assertion at runtime.
This is annoying because we can't get proper auto-completion of mlog,
and because ultimately it was allowing keyword arguments to be silently
dropped on the floor. This does make the code a little more verbose, but
I think the trade-offs of completion + better safety are worth it.
PEP692, which will be part of python 3.12, provides a more elegant
solution using `TypedDicts` to annotate `**kwargs`, which we should
consider in the future.
mypy is pretty dumb when it comes to unions of callables (pylance is
also dumb in this regard), and can't figure out that our use of
`mlog.debug | mlog.log` is perfectly safe. We also can't annotate them
properly to cast them to a valid subset of arguments because you can't
have splats in `typing.Callable`, so I've done enough to make it work.
There should be a way to make mypy happy without casting, but I can't
figure it out, since the mlog.error and mlog.debug actually have
different signatures.
After tracing all the way down to the bottom of this (or really, adding
annotations so mypy can) it turns out that passing file would just be
ignored at the end of the mlog call stack, so it should be removed
Hook this up to installed dependency manifests. This is often needed
above and beyond just an SPDX string -- e.g. many licenses have custom
copyright lines.
If `pkg-config --modversion foobar` fails, we don't know why. The
general issue here, though, is that call_pkgbin routinely logs stdout
for informational purposes, but not stderr.
Fixes#11076
Profiling showed that we were spending 25s inside os.path.realpath()
on Windows while generating compile lines for build.ninja, inside
NinjaBackend.generate()
The real path for these will not (should not) change during a single
meson invocation, so cache all these.
Brings build.ninja generation from 73s to 47s on my machine.
TAP 14 states:
> Harnesses may treat any TAP stream lacking a version as a failed test.
TAP 13 states:
> In the absence of any version line version 12 is assumed. It is an
> error to explicitly specify any version lower than 13.
So, modern TAP is saying that we should treat a missing version as a
test definition bug, it's no longer okay to use a missing version as
saying "let's use TAP 12". But, we can choose whether to treat it that
way or error out.
Let's do a diagnostic, as we do elsewhere. But allow TAP streams that
aren't well defined, if they used to be well defined (back in TAP 12).
Darwin-based systems, at least macOS, provide various JDK executable
stubs in
/System/Library/Frameworks/JavaVM.framework/Versions/*/Commands.
These stubs are placed in such a way that they break the heuristics of
the JNI system dependency. If a javac being analyzed to find a Java home
is a stub, use /usr/libexec/java_home.
See https://stackoverflow.com/a/15133344/7572728 for more details.
Closes#11173
ctypes uses FFI, and surprisingly often people's Python installations
will be broken because ctypes is broken (e.g. the system libffi has been
updated and Python needs to be recompiled). That is not our fault, but
it does manifest as Meson failing to run. It turns out we aren't even
using it though. At least, pretty often.
We have two uses of ctypes, and both of them are for Windows. One of
them is already conditionally imported in the function that uses it, but
the other is imported at startup. Move this down into the invoking
function.
On non-Windows systems, it is now impossible for Meson to fail to run
when ctypes is broken, because we don't use it. Anecdotally, this issue
tends to come up on Linux systems primarily.
Fixes#11111Closes#11112
fix_jar() tries to remove an existing Class-Path entry from the jar
manifest by postprocessing the manifest and passing it to `jar -um`.
However, `jar -um` can only add/replace manifest entries, not remove
them, and it also complains loudly when replacing an entry:
Dec 13, 2022 7:11:19 PM java.util.jar.Attributes read
WARNING: Duplicate name in Manifest: Manifest-Version.
Ensure that the manifest does not have duplicate entries, and
that blank lines separate individual sections in both your
manifest and in the META-INF/MANIFEST.MF entry in the jar file.
Thus fix_jar() produces one such warning for each entry in the manifest
and accomplishes nothing else.
Use jar -uM instead. This completely removes the manifest from the jar
and allows adding it back as a normal zip member, fixing fix_jar() and
avoiding the warnings.
Fixes: https://github.com/mesonbuild/meson/issues/10491
Fixes: c70a051e93 ("java: remove manifest classpath from installed jar")
Rather than passing arguments directly to less, set the LESS environment
variable to contain the desired arguments instead. This allows passing
arguments in case the user has PAGER=less set in their environment.
At least, if you tried to use it when passing an install_dir. Because
T.Sequence is horrible and we should never use it, and the annotations
are a lie that produces bugs.
So, fix the annotations on CustomTarget to never allow this to happen
again, and also fix the function too. Move some definitions elsewhere
inline to satisfy the linter.
Fixes#11157
T.Sequence is a questionable concept. The idea is to hammer out generic,
maximally forgiving APIs that operate on protocols, which is a fancy way
of saying "I don't care if you use tuples or lists". This is rarely
needed, actually, and in exchange for this fancy behavior you get free
bugs.
Specifically, `somestr` is of type `T.Sequence[str]`, and also
`somestr[0]` is another string of type you guessed it. It's ~~turtles~~
strings all the way down.
It's worth noting that trying to code for "protocols" is a broken
concept if the contents have semantic meaning, e.g. it operates on
"the install tags of this object" rather than "an iterable that supports
efficient element access".
The other way to use T.Sequence is "I don't like that T.List is
invariant, but also I don't like that T.Tuple makes you specify exact
ordering". This sort of works. In fact it probably does work as long as
you don't allow str in your sequences, which of course everyone allows
anyway.
Use of Sequence has cute side effects, such as actually passing lists
around, knowing that you are going to get a list and knowing that you
need to pass it on as a list, and then having to re-allocate as
`list(mylist)` "because the type annotations says it could be a str or
tuple".
Except it cannot be a str, because if it is then the application is
fatally flawed and logic errors occur to disastrous end user effects,
and the type annotations:
- do not enforce their promises of annotating types
- fail to live up to "minimal runtime penalties" due to all the `list()`
Shun this broken concept, by hardening the type annotations. As it turns
out, we do not actually need any of this covariance or protocol-ism for
a list of strings! The whole attempt was a slow, buggy waste of time.
There are two problems here: a typing problem, and an algorithm problem.
We expect it to always be passed to CustomTarget() as a list, but we ran
list() on it, which became horribly mangled if you violated the types
and passed a string instead. This caused weird*er* errors and didn't
even do anything. We want to do all validation in the interpreter,
anyway, and make the build level dumb.
Meanwhile we type it as accepting a T.Sequence, which technically
permits... a string, actually. This isn't intentional; the point of
using T.Sequence is out of a misguided idea that APIs are supposed to be
"technically correct" by allowing "anything that fulfills an interface",
which is a flawed concept because we aren't using interfaces here, and
also because "technically string fulfills the same interface as a list,
if we're talking sequences".
Basically:
- mypy is broken by design, because it typechecks "python", not "what we
wish python to be"
- we do not actually need to graciously permit passing tuples instead of
lists
As far as historic implementations of this logic go, we have formerly:
- originally, typeslistified anything
- switched to accepting list from the interpreter, redundantly ran list()
on the list we got, and mishandling API violations passing a string
(commit 11f9638035)
- switched to accepting anything, stringlistifying it if it was not
`None`, mishandling `[None]`, and invoking list(x) on a brand new list
from stringlistify (commit 157d438835)
- stopped stringlistify, just accept T.List[str | None] and re-cast to
list, violates typing because we use/handle plain None too
(commit a8521fef70)
- break typing by declaring we accept a simple string, which still
results in mishandling by converting 'foo' -> ['f', 'o', 'o']
(commit ac576530c4)
All of this. ALL of it. Is because we tried to be fancy and say we
accept T.Tuple; the only version of this logic that has ever worked
correctly is the original untyped do-all-validation-in-the-build-phase
typeslistified version.
Let's just call it what it is. We want a list | None, and we handle it too.
Eli Schwartz
Luke Elliott
Paolo Bonzini
Dylan Baker
Kleis Auke Wolthuizen
Jussi Pakkanen
Nirbheek Chauhan
Tristan Partin
Benjamin Gilbert
Brad Smith
Andreas Deininger
Phil Jones