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.
Dylan Baker
Andrea Pappacoda
Rohit Goswami
miebka
Eli Schwartz
Mat Cross
Paolo Bonzini
Evan Miller
Xavier Claessens
Tristan Partin
Jussi Pakkanen
David Seifert
Pamplemousse
Daniel Mensinger
Ian Harvey
Justin Handville