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
has_function() tries to link an example program using the function
to see if it is available, but with clang on 64bit Windows this
example always already failed at the compile step:
error: cast from pointer to smaller type 'long' loses information
long b = (long) a;
This is due to long!=pointer with LLP64
Change from "long" to "long long" which is min 64bit and should always
fit a pointer. While "long long" is strictly a C99 feature every
non super ancient compiler should still support it.
The builtin check had a special case that if a header was provided and
the function wasn't defined, it would ignore the builtin to avoid
non-functional builtins (for example __builtin_posix_memalign in MSYS2).
GCC 10 gained support for __has_builtin() which now skipps this check
and because __has_builtin(__builtin_posix_memalign) returns true the
non functional builtin is now reported as available.
To get the old behaviour back move the special case in front of the actual
availability check.
Fixes#7113
If no exe_wrapper is set in the meson cross file the exe_wrapper
object will be an instance of EmptyExternalProgram.
So, found is True and prorgram is an empty list.
This will cause meson to tun the compiler sanity check because
it checks only for self.is_cross and self.exe_wrapper being
not None.
I ran into that situation while cross compiling for ia32 on a
x64_64 host. The host had no ia32 userspace installed, so the
self test failed.
As workaround I currently set exe_wrapper to 'true'.
Signed-off-by: Richard Weinberger <richard@nod.at>
Error example:
Code:
#include <locale.h>
int main () {
/* If it's not defined as a macro, try to use as a symbol */
#ifndef LC_MESSAGES
LC_MESSAGES;
#endif
}
Compiler stdout:
Compiler stderr:
In file included from /usr/include/locale.h:25,
from /tmp/tmpep_i4iwg/testfile.c:2:
/usr/include/features.h:382:4: warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp]
382 | # warning _FORTIFY_SOURCE requires compiling with optimization (-O)
| ^~~~~~~
/tmp/tmpep_i4iwg/testfile.c: In function 'main':
/tmp/tmpep_i4iwg/testfile.c:8:9: error: control reaches end of non-void function [-Werror=return-type]
8 | }
| ^
cc1: some warnings being treated as errors
There is a pretty big error in here, trying to return a tuple
comperhension: (a for a in []) is not a tuple, it's a generator. This
has profound type annotations: generators don't support most tuple or
list methods, and they can only be iterated once. Beyond that tuples are
meant for heterogenous types, ie, position matters for types. I've
converted the output to a list in all cases.
The compilers module is rather large and confusing, with spaghetti
dependencies going every which way. I'm planning to start breaking out
the internal representations into a mixins submodule, for things that
shouldn't be required outside of the compilers module itself.
* correct handling of LDFLAGS in find_library and sanity_check on MSVC (fixes#3629)
The MSVC compiler requires all linker flags to be placed after the compiler flags, separated by a "/link" argument. This was already handled for regular linking commands, but not yet for the aforementioned special code paths.
* on MSVC, add /link separator between compiler and linker flags when it is missing
* avoid unnecessary /link argument
In most cases instead pass `for_machine`, the name of the relevant
machines (what compilers target, what targets run on, etc). This allows
us to use the cross code path in the native case, deduplicating the
code.
As one can see, environment got bigger as more information is kept
structured there, while ninjabackend got a smaller. Overall a few amount
of lines were added, but the hope is what's added is a lot simpler than
what's removed.
It was using ':' as a path separator while GCC uses ';' resulting in bogus
paths being returned. Instead assume that the compiler uses the platform native
separator.
The previous splitting code still worked sometimes because splitting
"C:/foo;C:/bar" resulted in the last part "/bar" being valid if "<DriveOfCWD>:/bar"
existed.
The fix also exposes a clang Windows bug where it uses the wrong separator:
https://reviews.llvm.org/D61121 . Use a regex to fix those first.
This resulted in linker errors when statically linking against a library which
had an external dependency linking against system libs.
Fixes#5386
Currently C++ inherits C, which can lead to diamond problems. By pulling
the code out into a standalone mixin class that the C, C++, ObjC, and
Objc++ compilers can inherit and override as necessary we remove one
source of diamonding. I've chosen to split this out into it's own file
as the CLikeCompiler class is over 1000 lines by itself. This also
breaks the VisualStudio derived classes inheriting from each other, to
avoid the same C -> CPP inheritance problems. This is all one giant
patch because there just isn't a clean way to separate this.
I've done the same for Fortran since it effectively inherits the
CCompiler (I say effectively because was it actually did was gross
beyond explanation), it's probably not correct, but it seems to work for
now. There really is a lot of layering violation going on in the
Compilers, and a really good scrubbing would do this code a lot of good.
Dylan Baker
Ole André Vadla Ravnås
Christoph Reiter
Andrew Udvare
Nirbheek Chauhan
Michael Hirsch, Ph.D
Andrei Alexeyev
Richard Weinberger
Daniel Mensinger
Xavier Claessens
Michael Hirsch, Ph.D
Aleksey Gurtovoy
Jehan
Martin Liska
David Seifert
Norbert Nemec
Charlie Barto
Norbert Nemec
Jussi Pakkanen
Marvin Scholz
Abhishek Pandit-Subedi
Cody Schafer
John Ericson