The Windows CI runs with codepage 1252, which is basically ISO-8859-1 and does not
have a mapping for character U+0151 (ő). It is currently passing because of a
happy accident, as the generator command line is emitted in UTF-8 anyway
(starting at commit 6089631a, "Open build files with utf-8", 2018-04-17, which
however lacks documentation or history) and file.py treats it as two
single-byte characters.
When going through meson_exe, however, Windows passes a genuine Unicode
character via CreateProcessW and file.py fails to decode it, so we need to
pass errors='replace' when opening the output file.
On Windows, the test is then fixed. On POSIX systems it is _still_ passing as
a happy accident because (according to the current locale) the output file
contains two single-byte characters rather than the single Unicode character
"ő"; in fact, if one modifies the ninja backend to use force_serialize=True,
meson_exe fails to build the command line for file.py and stops with a
UnicodeEncodeError.
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
Instead of trying to guess whether we need py or python3, and then
falling over when whatever we guessed isn't in the path or isn't right,
just use sys.executable which should always work.
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
Paolo Bonzini
ePirat
Martin Liska
Jussi Pakkanen
Marc-André Lureau
Dylan Baker
David Seifert
Thibault Saunier
Christoph Weiss
Nirbheek Chauhan
Michael Hirsch, Ph.D
Michael Hirsch, Ph.D
myfreeweb
Daniel Mensinger
Norbert Nemec
gjaeger1
Xavier Claessens