Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
As we now require python 3.6, we can declare their types without
initializing them.
|
|
This reverts commit c89aa2094170b2ffd7151187c1c092db2a178f44.
We no longer support 3.5 so this can go.
|
|
|
|
|
|
|
|
fix #9242
|
|
|
|
|
|
|
|
|
|
warning: ISO C does not allow extra ';' outside of a function [-Wpedantic]
|
|
If the compiler specified is a path to a compiler, the current detection is broken. It needs to use just the compiler name instead.
|
|
discovered via flake8 --select E303
|
|
"X not in Y" is preferred over "not X in Y", as the former is more
readable.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use appropriate compiler for the source file for "links" tests with file argument
|
|
More enhancements for Rust + clippy support
|
|
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
|
|
Otherwise we don't get critical arguments like -fuse=lld.
|
|
|
|
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".
|
|
|
|
Because mutation is bad.
|
|
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.
|
|
Add type annotations and type checking to meson main
|
|
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 c54dd63547b030e3d9feee694ec6f49c434f0df8
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.
|
|
The type information allows it, but it is not actually handled.
|
|
|
|
Fixes #8792
Fixes #8733
|
|
* 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
|
|
Currently every project that uses UTF8 for its source files must add
'/utf-8' argument otherwise they don't work non-English locale MSVC.
Since meson.build itself is assumed to be UTF8 by default, seems better
to assume it for source files by default too.
For example:
- https://gitlab.freedesktop.org/gstreamer/gst-build/-/blob/master/meson.build#L62
- https://gitlab.gnome.org/GNOME/glib/-/blob/main/meson.build#L29
|
|
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.
|