This basically existed for an assert which we don't need, as mypy would
catch that issue for us anyway. Removing the function entirely has some
small performance advantages
We already have to decide whether to scan a file at configure time, so
we don't want to have to do it again at compile time, every time the
depscan rule is run. We can do this by saving and passing the language
to use in the pickle, so depscan doesn't have to re-calculate it. As an
added bonus, this removes an import from depscan
We don't need to write and pass two separate files to the depscanner,
I've used the pickle because the pickle serializer/deserializer should
be faster than JSON, thought I haven't tested.
Now that we have access to Environment in get_assert_args, we can check what
the actual C++ stdlib provider is and only set relevant macros rather than
all possibly-relevant ones based on the compiler.
Also, while we're here, now that's sorted, wire up the GCC experimental
libc++ support in the macro emission given it doesn't uglify anything for
libstdc++ users now.
Bug: https://github.com/mesonbuild/meson/issues/12962
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
We're going to use it in some more places in a minute (for controlling assertions).
Bug: https://github.com/mesonbuild/meson/issues/12962
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
We'll need it in a moment for get_base_compile_args -> get_assert_args.
Bug: https://github.com/mesonbuild/meson/issues/12962
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Followup to 90098473d5.
If the compiler already has one of these assertion macros [0] set, then don't
interfere.
e.g. a Linux distribution might be setting a stricter default than usual. This
is a pitfall many fell into with _FORTIFY_SOURCE and it's why AX_ADD_FORTIFY_SOURCE [1]
was contributed to autoconf-archive.
[0] _GLIBCXX_ASSERTIONS, _LIBCPP_HARDENING_MODE, or _LIBCPP_ENABLE_ASSERTIONS.
[1] https://www.gnu.org/software/autoconf-archive/ax_add_fortify_source.html
Bug: https://github.com/mesonbuild/meson/issues/12962
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Followup to 90098473d5.
I changed my mind on this a few times. libcxx's documentation describes [0]
the hardening modes as:
"""
1) Unchecked mode/none, which disables all hardening checks.
2) Fast mode, which contains a set of security-critical checks that can be done
with relatively little overhead in constant time and are intended to be used
in production. We recommend most projects adopt this.
3) Extensive mode, which contains all the checks from fast mode and some additional
checks for undefined behavior that incur relatively little overhead but aren’t
security-critical. Production builds requiring a broader set of checks than fast
mode should consider enabling extensive mode. The additional rigour impacts performance
more than fast mode: we recommend benchmarking to determine if that is acceptable
for your program.
4) Debug mode, which enables all the available checks in the library, including
internal assertions, some of which might be very expensive. This mode is
intended to be used for testing, not in production.
"""
We chose 3) before because it felt like a better fit for what we're trying
to do and the most equivalent option to libstdc++'s _GLIBCXX_ASSERTIONS, but on
reflection, maybe we're better off picking a default with less overhead and
more importantly guarantees constant time checks.
[0] https://libcxx.llvm.org/Hardening.html#using-hardening-modes
Bug: https://github.com/mesonbuild/meson/issues/12962
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
They were skipped with llvm 17 based on the version, and they are
now no longer skipped with v18 and also pass now.
This depends on #12964 for llvm 18 support in meson.
It's utterly broken, and only works when one path is inside the other:
Traceback (most recent call last):
File "/usr/lib/python3.12/site-packages/mesonbuild/mesonmain.py", line 194, in run
return options.run_func(options)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/site-packages/mesonbuild/mdevenv.py", line 188, in run
write_gdb_script(privatedir, install_data, workdir)
File "/usr/lib/python3.12/site-packages/mesonbuild/mdevenv.py", line 142, in write_gdb_script
rel_path = gdbinit_path.relative_to(workdir_path)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.12/pathlib.py", line 682, in relative_to
raise ValueError(f"{str(self)!r} is not in the subpath of {str(other)!r}")
ValueError: '/path/to/builddir/.gdbinit' is not in the subpath of '/path/to/workdir'
ERROR: Unhandled python exception
This is a Meson bug and should be reported!
This fixes issues where a new option is added, an option is removed, the
constraints of an option are changed, an option file is added where one
didn't previously exist, an option file is deleted, or it is renamed
between meson_options.txt and meson.options
There is one case that is known to not work, but it's probably a less
common case, which is setting options for an unconfigured subproject.
We could probably make that work in some cases, but I don't think it
makes sense to download a wrap during meson configure.
When we load the option file in the interpreter record which file it
was, and what the hash of that file was. This will let `meson configure`
know that the options have changed since the last re-configure.
This demonstrates a limitation of Meson that can happen in the following
situation:
`meson setup builddir`
<update to meson.options> (such as git pull)
`meson configure -Dnew_option=value builddir`
<Error>
Since Meson is unaware of the updates to the meson.options file. The
purposes of these tests is to fix this behavior.
As far as we can ascertain, the idea here was supposed to be that this version
at the bottom gets updated as a last-resort for development LLVMs on Debian.
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
The test.json format currently has three keys related to skipping tests:
* `skip_on_jobname`
* `skip_on_os`
* `skip_on_env`
While `skip_on_env` marks the test itself as skipped, i.e. they don't get run when the
conditions are met, the other two skip options are just marking the test as "expected to be skipped"
if the conditions apply, i.e. they want to see `MESON_SKIP_TEST` in the output and things will
fail if that doesn't happen. They don't actually skip the tests as the names imply.
To make this clearer rename the keys:
* `skip_on_jobname` -> `expect_skip_on_jobname`
* `skip_on_os` -> `expect_skip_on_os`
`skip_on_env` stays the same, since that actually skips.
The docs were also confused about this, so adjust that too.
On Arch's shiny new 48-core/96-thread build server, the
`test_install_log_content` test fails because of an unexpected
`invalid-symlink.txt` file. Apparently the test runs in parallel with
`test_install_subdir_symlinks`, which modifies the `59 install subdir`
source directory.
To fix this, make `install_subdir_invalid_symlinks` copy the entire test
into a tmpdir before modifying it.
By adding the option name to UserOption object, it is now possible to
display the name of the affected option when the given option value is
not valid.
Fixes#12635
Otherwise internal dependencies have auto-generated names that are not
human readable. Instead, use the name that the dependency overrides. For
example:
```meson
meson.override_dependency('zlib', declare_dependency())
dep_zlib = dependency('zlib')
assert(dep_zlib.name() == 'zlib')
```
Fixes: #12967
When rustc cannot run host binaries it does an early return which
skipped getting native-static-libs. Move that code earlier to always run
it.
While at it, failing to determine those libs is a fatal error. We would
crash later when trying to access rustc.native_static_libs attribute
otherwise.
Places where compiler needs it already have access to Environment object
and can use it directly.
This fixes mypy complaining that not all compilers have self.exe_wrapper
in run() method that got moved to base class.
When doing a compiler check with a File object, there is no need to dump
the file into logs, we can just print the path. The file could
potentially be big.
The previous approach wasn't great because you couldn't control what the
detected C++ stdlib impl was. We just had a preference list we tweaked the
searched order for per OS. That doesn't work great for e.g. Gentoo with libc++
or Gentoo Prefix on macOS where we might be using libstdc++ even though the host
is libc++.
Jonathan Wakely, the libstdc++ maintainer, gave a helpful answer on how
to best detect libc++ vs libstdc++ via macros on SO [0]. Implement it.
TL;DR: Use <version> from C++20 if we can, use <ciso646> otherwise. Check for
_LIBCPP_VERSION as libstdc++ doesn't always define a macro.
[0] https://stackoverflow.com/a/31658120
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Version 1.9 removes support for python 3.7, so we either need to pin the
version to 1.8 as long as we're support Python 3.7, or we need to drop
linting for 3.7
Dylan Baker
Sam James
Christoph Reiter
Christopher Dilks
Nirbheek Chauhan
Stephan Lachnit
Jan Alexander Steffens (heftig)
Charles Brunet
Xavier Claessens
Yegor Yefremov
Jussi Pakkanen
Petr Machacek
Elliot