| Age | Commit message (Collapse) | Author |
|---|
|
The <lang>_stdlib can be used in cross files to use a custom standard library
for a given language.
When cpp_stdlib is used in a cross file, meson passes
* -nostdinc++ to the compiler
* -nostlib to the linker
According to [1] (gcc) and [2] (clang), we should pass -nostlib++ to the linker
when we don't want to link to the standard C++ library.
Currently, we pass -nostlib.
Fix this by implementing a C++ specific get_no_stdlib_link_args() function.
[1] https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#index-nostdlib_002b_002b
[2] https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-nostdlib
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
|
|
c++26 support was added in #11986, but regressed in #10332 because
the versions now get checked against the global _ALL_STDS list, and
c++26 was missing there.
Fix by adding c++26 to _ALL_STDS
|
|
Projects that prefer GNU C but can fallback to ISO C can now set for
example `default_options: 'c_std=gnu11,c11'` and it will use gnu11 when
available, fallback to c11 otherwise. It is an error only if none of the
values are supported by the current compiler.
This allows to deprecate gnuXX values from MSVC compiler, that means
that `default_options: 'c_std=gnu11'` will now print warning with MSVC
but still fallback to 'c11' value. No warning is printed if at least one
of the values is valid, i.e. `default_options: 'c_std=gnu11,c11'`.
In the future that deprecation warning will become an hard error because
`c_std=gnu11` should mean GNU is required, for projects that cannot be
built with MSVC for example.
|
|
add support for newer C++ -std= flags on Clang/GCC
|
|
Some various type related cleanups
|
|
GCC 12.3 and Clang 16 support -std flags for c++23/c++2b. The unreleased
GCC 14 and Clang 17 will support -std flags for c++26/c++2c.
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
|
|
The c++23 mappings apply to current production compilers (GCC, Clang).
None of the production c++ compilers support c++26 flags yet, but this
mapping will be ready once they do.
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
|
|
Names and types of some methods did not match their parent methods.
|
|
This matches the parent declaration.
|
|
Although mypy wasn't complaining, pyright was.
|
|
There were a ton of naked strings with TODOs telling us to use the enum.
|
|
Instead of hardcoding any values, hardcode what we think the most likely
implementation is, and check that first. It was pointed out that while
for example, Apple only provides libc++ and supports that for xcode, a
user could install a custom environment (such as homebrew) which uses
it's own copy of libstdc++, and we need to account for that. This means
that a library search will be done, but only once and the result will be
cached, on all systems.
|
|
The base implementation handles this already, with the added bonuses of
caching, and having one less code path to test.
|
|
Currently, we hardcode libc++ for MacOS (and derivatives), and libstdc++
for all other cases. Clang had some hackery to make this work in many
cases. However, this doesn't always work, namely if you try to to use
Rust as the linker when libc++ is required.
This implementation does, as an optimization, provide a hardcoded list
of OSes we know always use libc++, and otherwise will attempt to detect
it. As a second optimization, the detected values are cached, so the
lookup is only done once
fixes: #11921
|
|
Which will make subsequent work easier
|
|
It's slightly faster, and less code
|
|
We calculate them, but then don't use them. Clang does use them, so this
looks like a simple oversight
|
|
This saves on a 1500-line import at startup and may be skipped entirely
if no compiled languages are used. In exchange, we move the
implementation to a new file that is imported instead.
Followup to commit ab20eb5bbc21ae855bcd211131132d2778602bcf.
|
|
|
|
|
|
This could also be handled once, in the initializer
|
|
See https://github.com/llvm/llvm-project/commit/a8f75d49
|
|
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 22af56e05aa9cba4740d2ff303d876bb0c3cfb2b,
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
|
|
Only combine them in the Compiler base class, this will make easier to
run compiler without ccache.
|
|
|
|
|
|
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>
|
|
|
|
- mismatched method type
- mismatched parameter names
|
|
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 0b97d585480e973d8b149618901f7a4ddfa1a906
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.
|
|
|
|
It really is a per class value, and shouldn't be set per instance. It
also allows us to get rid of useless constructors, including those
breaking mypy
|
|
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
|
|
|
|
output and include args.
|
|
|
|
|
|
fix #9242
|
|
|
|
discovered via flake8 --select E303
|
|
|
|
|
