In the preceding commit we have started to perform compiler checks for
the value of `b_sanitize`, which allows us to detect sanitizers that
aren't supported by the compiler toolchain. But we haven't yet loosened
the option itself to accept arbitrary values, so until now it's still
only possible to pass sanitizer combinations known by Meson, which is
quite restrictive.
Lift that restriction by adapting the `b_sanitize` option to become a
free-form array. Like this, users can pass whatever combination of
comma-separated sanitizers to Meson, which will then figure out whether
that combination is supported via the compiler checks. This lifts a
couple of restrictions and makes the supporting infrastructure way more
future proof.
A couple of notes regarding backwards compatibility:
- All previous values of `b_sanitize` will remain valid as the syntax
for free-form array values and valid combo choices is the same. We
also treat 'none' specially so that we know to convert it into an
empty array.
- Even though the option has been converted into a free-form array,
callers of `get_option('b_sanitize')` continue to get a string as
value. We may eventually want to introduce a kwarg to alter this
behaviour, but for now it is expected to be good enough for most use
cases.
Fixes#8283Fixes#7761Fixes#5154Fixes#1582
Co-authored-by: Dylan Baker <dylan@pnwbakers.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
At the moment it turns out this mostly means... me. But this was
discussed publicly, as requested by a third party, and as per the newly
added page this is open to anyone in the Project who wishes to let it be
known that they accept donations.
Closes: https://github.com/mesonbuild/meson/issues/14262
It can sometimes be hard to find content without digging through menus.
Try to guide people towards the specific content they are probably
looking for.
The project in question still exists but no longer has a dedicated
domain; instead it uses a group website in theory for multiple projects
hosted by the same group (but in practice still just the one).
Apparently changed almost 2 years ago.
See: 0f53e40861
Executing tests can take a very long time. As an example, the Git test
suite on Windows takes around 4 hours to execute. The Git project has
been working around the issue by splitting up CI jobs into multiple
slices: one job creates the build artifacts, and then we spawn N test
jobs with those artifacts, where each test job executes 1/Nth of the
tests.
This can be scripted rather easily by using `meson test --list`,
selecting every Nth line, but there may be other projects that have a
similar need. Wire up a new option "--slice i/n" to `meson test` that
does implements this logic.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Persumably this list of was supposed to be alphabetized, but a few of
the items were out of order. This confused me because I was looking for
numpy, got the the Os and thought it wasn't there.
This adds --cap-lints allow, matching how Cargo builds them. In the case of
Cargo, this is only applied to non-path dependencies.
Without this change, clippy will complain about dependencies as well.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This is a better and more backwards-compatible way to disable all warnings,
compared to "-A warnings". The Rust RFC (https://rust-lang.github.io/rfcs/1193-cap-lints.html)
explains the rationale:
> We would very much like to be able to modify lints, however. For example
> rust-lang/rust#26473 updated the missing_docs lint to also look for missing
> documentation on const items. This ended up breaking some crates in the
> ecosystem due to their usage of #![deny(missing_docs)].
While at it, document that Rust deviates from the other languages in its
interpretation of warning_level=0.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Almost exactly the same as how the dl dependency works. On certain
systems (like BSDs that use clang), stdatomic is provided by compiler-rt
and doesn't need a separate library explictly linked. On a typical
GNU/LINUX system, atomic is a separate library that must be explictly
found and linked against. So just add a builtin and system method for
these two use cases.
clippy-driver is not meant to be a general-purpose compiler front-end.
Since Meson can now provide natively the ability to invoke clippy,
raise a warning if someone uses it that way.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This improves the handling of keyboard interrupt, and also makes it easy to
buffer the output and not mix errors from different subprocesses. This
is useful for clang-tidy and will be used by clippy as well. In addition,
the new code supports MESON_NUM_PROCESSES.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Even though the "targets" introspection info already includes the
command line arguments used to invoke the compiler, this is not
enough to correlated with the "compilers" introspection info and
get extra information from there.
Together with the existing "language" key, adding a "machine" key
is enough to identify completely an entry in the compilers info.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
It is useful to apply a limit to the number of processes even outside "meson test",
and specifically for clang tools. In preparation for this, generalize
determine_worker_count() to accept a variable MESON_NUM_PROCESSES instead of
MESON_TESTTHREADS, and use it throughout instead of multiprocessing.cpu_count().
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
There is actually very little overlap between `install_sources` and
`install_data` in arguments they accept: only 2/7 keywords for `install_data`
apply to `install_sources`.
Closes gh-12601
Meson allows to set the archiver via the `AR` environment variable and a
native / cross file. Only the latter approach seems to be documented.
This patch adds the `AR` environment variable to the reference tables
next to the compilers.
The quick example can be slightly misleading in implying that scan_xml
must use find_protocol, which is not the case. So explicitly mention it
in the scan_xml docs.