Currently, not only Meson lacks a way to induce a "--fatal-warnings" on
LINK.exe, it is also unable to pass flags appropriately when using
clang-cl or Microsoft's stock clang.
This commit fixes it by implementing `fatal_warnings()` in the
MSVCDynamicLinker and ClangCLDynamicLinker classes, and by implementing
the requisite conversion steps in linker_to_compiler_args for
ClangCompiler.
This way the `rust.bindgen` can generate a second output being a C file,
which contains wrapper functions for static inline ones.
This output file can then be compiled via C targets.
Followup to 7b7d2e060b which handles ASAN and UBSAN.
It turns out that MSAN needs the same treatment. I've checked other sanitizers
like HWASAN and TSAN - it looks like they may both need it too, but Meson doesn't
currently suppose those anyway (see https://github.com/mesonbuild/meson/pull/12648).
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
These are much easier to handle as one commit since msetup calls mconf
internally. This has found one case where things are being carefully
crafted to work in mconf even though msetup has slightly different
options
Instead of being instance state, it's passed around. This isn't a big
deal internally since most of the users are protected, and the only time
an external change is required is a couple of places in msubprojects,
which is fine because the information is available.
Fixes: #12869
These aren't meant to be called externally. Additionally, they expect
some statefulness from the `resolve()` method, and by making them
protected we can more easily remove this statefulness.
This code cleverly tried to use a fancy new pathlib.Path method to get
the os.path.commonpath of two paths and check whether one is inside the
other. It failed pretty badly, because of a hidden secret of pathlib: it
is designed to throw random exceptions at all times (except when
building os.PathLike interfaces) instead of performing useful work.
Return to `os.path`.
In particular, before this change, we wanted to check if files are NOT
in a subpath of `preserve_path_from`, and raise a meson "ERROR: xxx" in
such a case. However, the code to check for it would raise a python
ValueError if that was the case, so we never got to the properly
formatted error.
Since we don't get a location for these errors, we can at least tell you
which targets you happen to be mixing together that produce this
problem.
Ran into while trying to debug a target mixing bug.
0e7fb07 introduced a subtile bug in the Python module.
If a python version is found, but is missing a required module,
it is added to the list of python installations, but the
`run_bytecompile` attribute for that version was not initialized.
Therefore, if any other python version added something to install, it
was raising a KeyError when trying to read the `run_bytecompile`
attribute for the python version with missing module.
Using scan-build gives the following warning:
"Running the setup command as `meson [options]` instead of
`meson setup [options]` is ambiguous and deprecated."
This commit fixes this issue by adding the setup keyword to the meson command.
The .lcovrc file can contain several directives for genhtml, mostly
pertaining the visualisation of the generated HTML report. Passing the
config file to genhtml allows the user to customize their report.
Fixes#12863
Special notes:
- _nvcc_arch_flags is always called with exact arguments, no need for
default values
- min_driver_version has its args annotation loosened because it has to
fit the constraints of the module interface?
The min_driver_version function has an extensive, informative custom
error message, so leave that in place.
The other two functions didn't have much information there, and it's
fairly evident that the cuda compiler itself is the best thing to have
here. Moreover, there was some fairly gnarly code to validate the
allowed values, which we can greatly simplify by uplifting the
typechecking parts to the dedicated decorators that are both really good
at it, and have nicely formatted error messages complete with reference
to the problematic functions.
It is pretty trivial and more confusing when standalone, especially the
use of a sentinel "unknown" string as a standin for "this isn't one of
the allowed object types". Much easier to directly raise an error in the
fallthrough/else.
It is only ever invoked once. It has a statically known signature based
on how it's used, so there's no good reason to allow it to accept any
defaults -- and defaulting to None messes with type safety.
Saturate is always given, so don't claim it is only sometimes.
IfClauseNode is only ever initialized in such a way that this attribute
is immediately set to something valid. And attempting to access its
value when the value is None would be a pretty broken error anyway. The
assignment served no purpose, but did perform a frivolous runtime op in
addition to angering mypy's checks for implicit None.
An oddity: sys.stdout is statically defined as type TextIO instead of
TextIOWrapper, and thus doesn't have a .reconfigure method. This is
because they expect people to override sys.stdout with other objects,
which we do not do. Instead, assume it is always correct.
There are two final errors due to metaprogramming:
```
mesonbuild/mesonmain.py:196:13: error: Returning Any from function declared to return "int" [no-any-return]
mesonbuild/mesonmain.py:225:9: error: Returning Any from function declared to return "int" [no-any-return]
```
The add_arguments function is always called with a formatter in
mesonmain.py, and if it were not, then it would be incorrect when
calling argparse itself -- because formatter_class cannot be None, and
defaults to its own builtin one. This violates None-safety.
Instead of returning Optional, a state that is only possible during
`__init__` and which prevents mypy from knowing what it is safe to
assume it will get.
L. E. Segovia
Tristan Partin
dragonmux
Karol Herbst
Charles Brunet
Sam James
Dylan Baker
Ole André Vadla Ravnås
Eli Schwartz
Stephan Lachnit
Esther Dalhuisen