If this command fails, for example when CXX is something not generic
enough to be a valid universal compiler command (clang -std=c++11
perhaps), we end up with two problems:
- it's impossible to figure out what Meson ran to get that error
- the error report isn't clear on what is stdout and what is stderr, or
even that that is what the message is about.
```
meson.build:1:0: ERROR: Unable to get clang pre-processor defines:
error: invalid argument '-std=c++11' not allowed with 'C'
```
What's C doing there and why is Meson talking about it? Answer: that's
compiler stdout. Say so.
We do something similar when running get_compiler() method checks from
the DSL. This ensures that if errors happen, the log file we tell people
to check actually works.
Specifically, this is a combination of the following:
- Revert "visualstudio.py: Apply /utf-8 only on clang or VS2015+"
This reverts commit 6e7c3efa79.
- Revert "Visual Studio: Only use /utf-8 on VS2015 or later or clang-cl"
This reverts commit 8ed151bbd7.
The changes were broken and untested, although this is because of a lack
of general CI testing for all languages on Windows. At least, this broke
the use of ifort, and possibly more.
The changes are fundamentally a bit "exciting", as they step out of the
hierarchy of compiler definitions and apply arguments almost willy-nilly.
And apparently it's leaky all over the place. I don't understand all of
what is going on with it, but it plainly failed to achieve its desired
goal and needs to be rolled back ASAP.
Transpilers need to run on the build machine in order to generate their
output, which can then be taken by a cross-compiler to create the final
output.
MachineChoice is a mesonlib object, not a compilers object, so it makes
no sense to import it from the latter simply because the latter imports
it too. This results in brittle module dependencies and everything
breaking when a refactor removes it from the latter.
... also it is a typing-only import so while we are fixing it to import
from the right place, we can also put it in a type-checking block.
In PR 10263, we didn't account for that we may have initialize the Visual
Studio-like compiler two times, once for a C compiler and once for the
C++ compiler, so we end up with Meson breaking on Visual Studio 2013
or earlier, such as when building GLib.
Fix this by setting up the always_args member of
the VisualStudioLikeCompiler instance during __init__() as needed, so that
we avoid falling into modifying shared objects.
Leak sanitizer can be enabled without the whole AddressSanitizer, this
can be done by passing -fsanitize=leak as documented at [1].
Meson doesn't support this, so add support for it.
[1] https://clang.llvm.org/docs/LeakSanitizer.html
This option is only valid for C++ and ObjC++, but the kwarg is useful
for mixed language targets. Asking for inlines as well, when the
compiler driver is trying to build the C components of a target, results
in gcc emitting:
```
cc1: warning: command-line option ‘-fvisibility-inlines-hidden’ is valid for C++/ObjC++ but not for C
```
Squelch this warning by filtering it out on Meson's side of things.
Otherwise it always returns the value for c++98, starting with MSVC 2017
15.7 or later. Earlier versions are not affected by this mis-feature.
See: https://docs.microsoft.com/en-us/cpp/build/reference/zc-cplusplus?view=msvc-160
This was originally applied as 0b97d58548
but later reverted because it made the CI red. Try it again, now.
Original-patch-by: Dylan Baker <dylan@pnwbakers.com>
Co-authored-by: Dylan Baker <dylan@pnwbakers.com>
[why]
Support for the relatively new mold linker is missing. If someone wants
to use mold as linker `LDFLAGS="-B/path/to/mold"` has to be added instead
of the usual `CC_LD=mold meson ...` or `CXX_LD=mold meson ...`.
[how]
Allow `mold' as linker for clang and newer GCC versions (that versions
that have support).
The error message can be a bit off, because it is generic for all GNU
like compilers, but I guess that is ok. (i.e. 'mold' is not listed as
possible linker, even if it would be possible for the given compiler.)
[note]
GCC Version 12.0.1 is not sufficient to say `mold` is supported. The
expected release with support will be 12.1.0.
On the other hand people that use the un-released 12.0.1 will probably
have built it from trunk. Allowing 12.0.1 is helping bleeding edge
developers to use mold in Meson already now.
Fixes: #9072
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
The compiler flag only exists on Visual Studio 2015 or later, or clang-cl,
and using this always can interfere with compiler feature detection when
this flag is not supported.
So, remove '/utf-8' from always_args if we are on Visual Studio 2013 or
earlier.
This has been broken ever since the original implementation. Due to a
typo, the optimization flag used a zero instead of an uppercase "o",
which the compiler then breaks on during argument parsing because it is
an invalid argument.
Fixes#10267
When something goes wrong with running the compiler in
_symbols_have_underscore_prefix_searchbin, print stderr instead,
as it actually contains helpful output while stdout is usually empty
in this case.
Fixes the following ResourceWarnings:
ResourceWarning: subprocess 25556 is still running
_warn("subprocess %s is still running" % self.pid,
ResourceWarning: Enable tracemalloc to get the object allocation traceback
mesonbuild/compilers/mixins/gnu.py:195: ResourceWarning: unclosed file <_io.BufferedReader name=4>
return gnulike_default_include_dirs(tuple(self.exelist), self.language).copy()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
It is always used as an immutable view so there is no point in doing
copies. However, mypy insist it must implement the same APIs as
Dict[OptionKey, UserOption[Any]] so keep faking it.
The code in the C++ and Fortran compilers' language_stdlib_only_link_flags
method is broken and cannot possibly have ever worked. Instead of
splitting by line, it splits by whitespace and therefore, instead of
the last line of the compiler output:
programs: =/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
libraries: =/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/12.0.0
it is only the last field that has its first 11 characters removed.
Instead of reinventing the wheel with a new and brittle pattern,
reuse get_compiler_dirs.
Fixes: 64c267c49 ("compilers: Add default search path stdlib_only_link_flags", 2021-09-25)
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Using future annotations, type annotations become strings at runtime and
don't impact performance. This is not possible to do with T.cast though,
because it is a function argument instead of an annotation.
Quote the type argument everywhere in order to have the same effect as
future annotations. This also allows linters to better detect in some
cases that a given import is typing-only.
GCC with optimization set to 0 does not actually result in no
optimizations, which can be annoying when trying to use a debugger like
gdb, and finding that your variable has been optimized out. We already
do this with clang, so gcc is a bit of an outlier here.
We didn't consider that it has arguments following it, so the resulting
compiler command line ended up with stuff like:
-L=-rpath-link -L=-L=/path/to/directory -L=more-args
and the directory for rpath-link got eaten up as a regular -L path to
the compiler rather than being passed as -Xlinker to the linker.
Then the -rpath-link would consume the next -Xlinker argument, end up
with the wrong rpath-link (may or may not cause link errors) and then
disappear arguments we need.
As an example failure mode, if the next argument is -soname this treats
the soname text as an input file, which probably does not exist if it
was generated in a subdirectory, and also because it can never be
successfully built in the first place -- though if it did, it would link
to itself which is very wrong.
This is another toolchain also called `armclang`, but it is not a cross
compiler like Keil's `armclang`. It is essentially the same as `clang`
based on its interface and CMake's support of the toolchain.
Use an `armltd` prefix for the compiler ID.
Fixes: #7255
Removed errant "type: ignore".
Fixed issue with "fetch" call. This issue was the following:
Dict::get() and Dict::pop() have the following signature:
T.Callable[[_T, _U], _U | None] OR T.Callable[[_T], _U | None]
Note how the return type is _U here. When the fetch() function was
actually being called, it had the following signature:
T.Callable[[_T, T.List[_U]], T.Union[T.List[_U], _U]]
This is incompatible with the previous definitions. The solution is
simply to move where the default value is introduced if fetch() produces
None.
If the LTO threads == 0 clang will default to the same argument we
manually pass, which meant we dropped support for admittedly ancient
versions of clang that didn't yet add that option.
Drop the extraneous argument, and add a specific error condition when
too old versions of clang are detected.
Fixes#9569
Clippy is a compiler wrapper for rust that provides an extra layer of
linting. It's quite popular, but unfortunately doesn't provide the
output of the compiler that it's wrapping in it's output, so we don't
detect that clippy is rustc. This small patch adds a new compiler class
(that is the Rustc class with a different id) and the necessary logic to
detect that clippy is in fact rustc)
Fixes: #8767
Currently this implements 3 warning levels, 1 and 2 are just the
"default" set by rustc, 3, is "everything is a warning", and 0 is
"nothign is a warning".
This should be done in all cases of language_stdlib_only_link_flags, but
I don't have access to all of the compilers to test it.
This is required in cases where object files created by gfortran are
linked using another compiler with a differen default search path, such
as gfortran and clang together.
This patch adds a new meson built-in option for cython, allowing it to
target C++ instead of C as the intermediate language. This can, of
course, be done on a per-target basis using the `override_options`
keyword argument, or for the entire project in the project function.
There are some things in this patch that are less than ideal. One of
them is that we have to add compilers in the build layer, but there
isn't a better place to do it because of per target override_options.
There's also some design differences between Meson and setuptools, in
that Meson only allows options on a per-target rather than a per-file
granularity.
Fixes#9015
I ran into one of these from LGTM, and it would be nice if pylint could
warn me as part of my local development process instead of waiting for
the CI to tell me.
-Oz is the appropriate flag to use when you want to produce the smallest
possible binary, and is one would expect when setting optimization to s
or using the minsize build type.
It is imported from a subpackage in __init__ alongside a big list of
other things which are all exported. And elsewhere, this import is
re-imported by other code. It's pretty clearly an oversight that it
didn't get added to __all__
The clang compiler now reimplements and re-checks the c_std and cpp_std
options in order to use them for objc as well, but it didn't
consistently support the same options. First it completely excluded all
the gnu ones, and then it added a handful of them but not for C++.
Be fully consistent -- or at least as consistent as we can be, given a
minimally working fix. (The C/C++ compiler mixin actually gates
different stds depending on detected clang version, we do not do that
here.)
Fixes regression in c54dd63547
Fixes incomplete fix from #8766 (which didn't fix objcpp at all)
Fixes#9237
Allow using the links method to test that the C++ driver (e.g. g++) can be used to
link C objects. One usecase is that the C compiler's libsanitizer might not be
compatible with the one included by the C++ driver.
This is theoretically backwards-incompatible, but it should be treated as a
bugfix in my opinion. There is no way in Meson to compile a .c file with the
C++ driver as part of a build target, therefore there would be no reason to
do something like meson.get_compiler(meson.get_compiler('cpp').links(files('main.c')).
Fixes: #7703
In some cases, link tests would like to use objects provided by a compiler
for a different language, for example linking a C object file with a C++
compiler. This kind of scenario is what link_language is for, but it is
impossible to test that it works with a linker test.
This patch implements the required support in the Compiler class. The
source code compiler is passed to the Compiler.links method as an
argument.
* compilers: improve docstring to `get_compiler_check_args()`
There was an incomplete list, which wasn't useful as it now takes an
enum anyway. Also add a new entry to the list of reasons to use this
function.
* clang: Add -Werror=implicit-function-declarations to check_args
Unlike GCC, clang warns but doesn't error when an implicit function
declaration happens. This means in checks like
`compiler.has_header_symbol('string.h', 'strlcat')` (on Linux, at least)
that GCC will fail, as there is no such function; clang will emit a
warning, but since it exists with a 0 status Meson interprets that as
success. To fix this, add `-Werror=implicit-function-declarations` to
clang's check arguments.
There seems to be something specific about functions that _may_ exist in
a header on a given system, as `cc.has_header_symbol('string.h',
'foobar')` will return false with clang, but `strlcat` will return true,
even though it's not defined. It is however, defined in some OSes, like
Solaris and the BSDs.
Fixes#9140
We have a lot of these. Some of them are harmless, if unidiomatic, such
as `if (condition)`, others are potentially dangerous `assert(...)`, as
`assert(condtion)` works as expected, but `assert(condition, message)`
will result in an assertion that never triggers, as what you're actually
asserting is `bool(tuple[2])`, which will always be true.
There are two changes here, one is to remove an `elif` that is
effectively an `else`, that helps the type checker and provides a small
speedup potentially. The second is a potentially unbound variable, that
currently isn't hit, but very much could be.
Eli Schwartz