There are lots of warnings that become fatal, that are simply unfixable
by the end user. Things like using old versions of software (because
they're using some kind of LTS release), warnings about compilers not
supporting certain kinds of checks, or standards being upgraded due to
skipped implementations (MSVC has c++98 and c++14, but not c++11). None
of these should be fatal, they're informative, and too important to
reduce to notices, but not important enough to stop meson if they're
printed.
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.
-Wnon-virtual-dtor is not what people think of as a standard warning
flag. It was previously removed from -Wall in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16190 on the grounds that
people didn't like it and were refusing to use -Wall at all because it
forced this warning. Instead, it is enabled by -Weffc++ which is
typically not enabled and even comes with GCC documentation warnings
stating that the standard library doesn't obey it, and you might need to
`grep -v` and filter out warnings. (!!!)
It doesn't fit into the typical semantics of Meson's warning_level
option, which usually aligns with compiler standard warning levels
rather than a niche ideological warning level.
It was originally added in commit 22af56e05a,
but without any specific rationale included, and has gone unquestioned
since then -- except by the Meson users who see it, assume there is a
finely crafted design behind it, and quietly opt out by rolling their own
warning options with `add_project_arguments('-Wall', ...)`.
Furthermore a GCC component maintainer for the C++ standard library
opened a Meson bug report specially to tell us that this warning flag is
a "dumb option" and "broken by design" and "doesn't warn about the right
thing anyway", thus it should not be used. This is a reasonably
authoritative source that maybe, just maybe, this flag... is too
opinionated to force upon Meson users without recourse. It's gone beyond
opinionated and into the realm of compiler vendors seem to think that
the state of the language would be better if the flag did not exist at
all, whether default or not.
Fixes#11096
We compared a Visual Studio (the IDE) version, but we wanted a MSVC (the
compiler) version. This caused the option to be passed for a few too
many versions of MSVC, and emit a "D9002 : ignoring unknown option" on
those systems.
Compare the correct version using the version mapping from
https://walbourn.github.io/vs-2017-15-7-update/Fixes#10787
Co-authored-by: CorrodedCoder <38778644+CorrodedCoder@users.noreply.github.com>
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>
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.
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
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.
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.
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.
Dependencies is already a large and complicated package without adding
programs to the list. This also allows us to untangle a bit of spaghetti
that we have.
This has a bunch of nice features. It obviously centralizes everything,
which is nice. It also means that env is only re-read at `meson --wipe`,
not `meson --reconfigure`. And it's going to allow more cleanups.
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.
And then update the choices in each leaf class. This way we don't end up
with another case where we implicitly allow an invalid standard to be
set on a compiler that doesn't have a 'std' setting currently.
Jussi Pakkanen
Dylan Baker
Luke Elliott
Kleis Auke Wolthuizen
David Robillard
Eli Schwartz
Xavier Claessens
Robert Cohn
Tristan Partin
Paolo Bonzini
William Toohey
Ben Boeckel
Nathanael Gray
Moroz Oleg
Christian Clauss
makise-homura
Florian Schmaus
Vinson Lee