ClangClCPPCompiler.get_options() registers 'vc++23' as a valid cpp_std
value (since commit 3b7c81d4, 'clang-cl: add c++23 support ...'), but
'vc++23' was never added to the ALL_STDS list that backs the cpp_std
UserStdOption. UserStdOption.set_versions() therefore trips its
assert all(std in self.all_stds for std in versions)
as soon as a clang-cl C++ compiler is detected, aborting configuration
with an AssertionError ("Unhandled python exception") for every C++
project built with clang-cl. MSVC is unaffected because it never
registers the vc++23 standard.
Add the missing 'vc++23' entry so the compiler's advertised stds are a
subset of ALL_STDS again.
clang-cl supports C++11 natively, so CPP11AsCPP14Mixin is not needed.
Override get_option_std_args to use /clang:-std=c++N for all standards
except c++latest/vc++latest which still require /std:c++latest. Add
c++23 and vc++23 to the supported standards list.
Fixes#15845
Two improvements so the compiler sanity check exercises the same code
paths as cc.links():
1. Compiler._sanity_check_compile_args (the base class) now passes
get_external_args() and get_external_link_args() to the probe, just
as build_wrapper_args() does. CLikeCompiler already did this via
_get_basic_compiler_args(); the base class fix extends it to non-CLike
compilers (Fortran, Swift, etc.). Duplicates in the CLike path are
harmless because arglist deduplicates them.
2. CCompiler and CPPCompiler sanity check sources now include <stddef.h>.
This ensures that a broken or missing include path is caught at
compiler detection time with a natural compiler error, rather than
surfacing later as a cryptic Meson exception.
- Use `lru_cache` for `quote_arg`,
`_StdCPPLibMixin.language_stdlib_provider` and
`NinjaBackend._generate_single_compile_base_args`.
- Cache calls to `platform.system().lower()` and
`platform.release().lower()`.
With this, I see a ≈10% speedup of Ninja rule generation for a somewhat
large project.
The goal is to reduce code duplication, and allow each language to
implement as little as possible to get good checking. The main
motivation is that half of the checks are fragile, as they add the work
directory to the paths of the generated files they want to use. This
works when run inside mesonmain because we always have an absolute build
directory, but when put into run_project_tests.py it doesn't work
because that gives a relative build directory.
Additionally, this fixes the implementation of sanity checking for
transpiled languages like Vala and Cython, which previously didn't test
the output of their compilers at all, but re-ran the C compiler test for
itself.
This is calculated by `Environment().is_cross_build(for_machine)`. Since
we have that in the Compiler class, just calculate it in the Compiler
initializer
We end up needing it everywhere, so just store it. This patch is huge
already, so it's just the conversion to passing Environment, more
cleanups to come.
The IntelCPPCompiler was incorrectly adding -fno-rtti when RTTI was
enabled (rtti=True) instead of when it was disabled. This change
corrects the logic to match the behavior of GCC and Clang compilers,
which properly add -fno-rtti when rtti=False.
Fixes#15220
libc++ uses the same macro name, just with different values, for debugstl.
If the distro or similar predefines a hardening mode lower than the mode
debugstl wants (or in any other way not equal), we get an annoying redefinition
warning.
Closes: https://github.com/mesonbuild/meson/issues/13812
The Microchip XC32 compiler is a GCC-based compiler implemented using
existing GNU compiler classes. As the XC32 version and GCC version do
not match mixins have been implemented to override versions used in
versions checks where applicable.
The goal is to reduce code duplication, and allow each language to
implement as little as possible to get good checking. The main
motivation is that half of the checks are fragile, as they add the work
directory to the paths of the generated files they want to use. This
works when run inside mesonmain because we always have an absolute build
directory, but when put into run_project_tests.py it doesn't work
because that gives a relative build directory.
Fixes a regression introduced in commit d37d649b08 "Make all Meson level
options overridable per subproject." This change results in every file
printing the warning "cl : Command line warning D9002 : ignoring unknown
option '/std:vc++14'"
Now that "get_option_..." is called before overwriting the option (instead
of after), we have to operate on compiler options, not meson options.
There is no such compiler option as /std:vc++14 (the meson option vc++xx is
split into /std:c++xx for the C++ standard version, and a separate flag
that enables Microsoft extensions). Remove the mapping from c++14 to
vc++14.
libc++ deprecated _LIBCPP_ENABLE_ASSERTIONS from version 18.
However, the libc++ shipped with Apple Clang backported that
deprecation in version 17 already,
which is the version which Apple currently ships for macOS.
This PR changes the _LIBCPP_ENABLE_ASSERTIONS deprecation check
to use version ">=17" on Apple Clang.
Move building the -std option to the new get_option_std_args method,
special casing CUDA to never include the option from the host compiler.
This fixes again #8523, which was broken by the option refactoring
(unsurprisingly, since the fix was ripped out unceremoniously without
a replacement).
Fixes: #14365
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This is just a wrapper around `OptionStore.get_option_for`, but without
taking an `OptionKey`. This complicates the subproject passing, since
`OptionKey` is designed to encapsulate the option name and subproject.
This reduces code, makes this clearer, and will be a nice step toward
the goal of getting everything typesafe.
For `UserIntegerOption` this makes a fairly nice, but substantial change
in that the old method used a tuple of `(min, value, max)` to pass to the
initializer, while all other types just passed `value`. The new
`UserIntegerOption` does the same, with keyword arguments for the min
and max values.
This saves a *tiny* bit of typing, but at the cost of requiring either
the current solution of throwing up our hands and saying "typing is too
hard, better to have bugs!" or an extensive amount of `TypedDict`s,
`overloads`, and a very new version of mypy. Let's get our type safety
back, even if it means writing a little bit more code.
