This option was introduced with GCC 8.1.0 as in the original commit, but the
value wasn't right initially and was volatile during the 8 series.
To avoid this, this commit moves the warning to 9.1.0 (the next version we
generally care about), since we don't want to get too deep into the weeds of
point releases, and a warning not being used yet in some particular version of
GCC isn't a big deal.
Adds a new maximum warning level that is roughly equivalent to "all warnings".
This adds a way to use `/Wall` with MSVC (without the previous broken warning),
`-Weverything` with clang, and almost all general warnings in GCC with
strictness roughly equivalent to clang's `-Weverything`.
The GCC case must be implemented by meson since GCC doesn't provide a similar
option. To avoid maintenance headaches for meson, this warning level is
defined objectively: all warnings are included except those that require
specific values or are specific to particular language revisions. This warning
level is mainly intended for new code, and it is expected (nearly guaranteed)
that projects will need to add some suppressions to build cleanly with it.
More commonly, it's just a handy way to occasionally take a look at what
warnings are present with some compiler, in case anything interesting shows up
you might want to enable in general.
Since the warnings enabled at this level are inherently unstable with respect
to compiler versions, it is intended for use by developers and not to be set as
the default.
ccache was used in all command lines but disabled using CCACHE_DISABLE
in Compiler.compile() method. Wrapping invokations still has a cost,
especially on Windows.
With sccache things are even worse because CCACHE_DISABLE was not
respected at all, making configure *extremely* slow on Windows when
sccache is installed.
https://github.com/mesonbuild/meson/pull/9287 changed the `optimization=0`
to pass `-O0` to the compiler. This change is reasonable by itself
but unfortunately, it breaks `buildtype=plain`, which promises
that “no extra build flags are used”.
`buildtype=plain` is important for distros like NixOS,
which manage compiler flags for optimization and hardening
themselves.
Let’s introduce a new optimization level that does nothing
and set it as the default for `buildtype=plain`.
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.
[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>
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
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.
When mutable items are stored in an lru cache, changing the returned
items changes the cached items as well. Therefore we want to ensure that
we're not mutating them. Using the ImmutableListProtocol allows mypy to
find mutations and reject them. This doesn't solve the problem of
mutable values inside the values, so you could have to do things like:
```python
ImmutableListProtocol[ImmutableListProtocol[str]]
```
or equally hacky. It can also be used for input types and acts a bit
like C's const:
```python
def foo(arg: ImmutableListProtocol[str]) -> T.List[str]:
arg[1] = 'foo' # works while running, but mypy errors
```
Both Clang and GCC support using multiple threads for preforming link
time optimizaions, and they can now be configured using the
`-Db_lto_threads` option.
Fixes#7820
I would have prefered to do these seperatately, but they are combined in
some cases, so it was much easier to convert them together.
this eliminates the builtins_per_machine dict, as it's duplicated with
the OptionKey's machine parameter.
We do this by making the mixins inherit the Compiler class only when
mypy is examining the code (using some clever inheritance shenanigans).
This caught a bunch of issues, and also lets us delete a ton of code.
Currently we do some crazy hackery where we add extra properties to a
Popen object and return that. That's crazy. Especially since some of our
hackery is to delete attributes off of the Popen we don't want. Instead,
let's just have a discrete type that has exactly the properties we want.
D lang compilers have an option -release (or similar) which turns off
asserts, contracts, and other runtime type checking. This patch wires
that up to the b_ndebug flag.
Fixes#7082
compiler.get_supported_arguments reports success for certain unsupported
flags when using the gnu C/ObjC, C++/ObjC++ compilers. This fix reads
the stderr on the has_arguments check to ensure the arguments really are
supported and not valid for the language selection
Now that the linkers are split out of the compilers this enum is
only used to know what platform we're compiling for. Which is
what the MachineInfo class is for
Instead of the DynamicLinker returning a hardcoded value like
`-Wl,-foo`, it now is passed a value that could be '-Wl,', or could be
something '-Xlinker='
This makes a few things cleaner, and will make it possible to fix using
clang (not clang-cl) on windows, where it invokes either link.exe or
lld-link.exe instead of a gnu-ld compatible linker.
There are two problems, one is that it assumes -flto is the argument
to do LTO/WPO, which isn't true of ICC and MSVC (and presumably)
others. It's also incorrect because it assumes that the compiler and
linker will always be the same, which isn't necessarily true. You
could combine GCC with Apple's linker, or clang with link.exe, which
use different arguments.