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
fixes instability in precise version of tools resulting in some runners
getting a downgraded version and producing spuriously fixed/reintroduced
codeql alerts.
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.
The documentation for build_target(...) does not list file or str as
the possible types for the "objects" keyword argument, even though in
theory the argument is meant for prebuild object files that are part
of the sources.
Of course that is only the theory, because an ExtractedObjects object
is probably used a lot more than a file in the source tree. But
at least make the reference manual's typing information accurate.
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
Link to feature options consistently, and point out that it controls
"whether" the function finds what it's trying to find. This clues people
in to the fact that disabled features exist.
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")
Dylan Baker
Eli Schwartz
Stephan Lachnit
Kleis Auke Wolthuizen
Jussi Pakkanen
Nirbheek Chauhan
Oliver Kraitschy
Paolo Bonzini
Michael Hirsch
Xavier Claessens
Amit D
Tristan Partin
Benjamin Gilbert
Brad Smith