Starting with VS 2017 if the output of any command run by VS contains
the word Error it will interpret that as a fatal error, even if the exit
error code is zero.
This messes up the unit tests on VS 2017, because we sometimes want to
deliberately ignore error messages.
Change "Error" to "Problem" to mitigate this issue until a more
permanent solution is found.
Fix exception handling of missing rustc, by making it look like the other
compiler detectors
Traceback (most recent call last):
File "/wip/meson/mesonbuild/environment.py", line 699, in detect_rust_compiler
p, out = Popen_safe(compiler + ['--version'])[0:2]
[...]
FileNotFoundError: [Errno 2] No such file or directory: 'rustc': 'rustc'
During handling of the above exception, another exception occurred:
[...]
File "/wip/meson/mesonbuild/environment.py", line 701, in detect_rust_compiler
popen_exceptions[compiler] = e
TypeError: unhashable type: 'list'
Since PR #2884, this is failing with an exception
Keep the behaviour we have had since PR #1810 (0.41.0), that ordering
comparisons of different types fail with an InterpreterException.
Also warn about equality comparisons of different types, which will one day
become an error, as per PR #2884.
PR #2527 suggests "making failing tests more strict about failing
gracefully".
To achive this, make meson exit with distinct exit statuses for meson errors
and python exceptions, and check the exit status is as expected for failing
tests.
I can't see how to write a test for this, within the current framework.
You can test this change by reverting the fix (but not the test) from commit
1a159db8 and verifying that 'test cases/failing/66 string as link target'
fails.
Currently we try both C and C++ when determining which PCH files to
include. The problem with this approach is that if there are no C or C++
files (only headers) and the target has both C and C++ sources then the
PCHs will be passed to the wrong compiler.
The solution is less code, we already have the compiler, the compiler
knows what language it is, so we don't need to walk both C and C++.
Fixes#3068
Since c2a5ac39, MesonApp.generate() closes the logfile before returning,
which means that when invoked by mesonmain.run(), any MesonException is not
logged there.
MesonApp.generate() does not appear to have any other users I can find.
This somewhat reduces the diagnostic value of the logfile.
This also interacts badly with running project tests in CI, as _run_tests
chooses to report the logfile contents, rather than stdout, for the
configure step, and it thus doesn't report any configure error which caused
a test failure.
Setting MALLOC_PERTURB_ to a non-zero value is fine for regular test
cases. It helps catching bugs, but also comes with some runtime
overhead.
This overhead is noticeable for benchmarks when compared to running them
directly instead of through Meason.
Therefore, MALLOC_PERTURB_ is not touched for benchmarks.
closes#3034
Previously, Meson was showing a subproject being downloaded after later
claiming it doesn't exist.
This patch shows the actual error to clarify why the given subproject
can not be used.
The '+' and 'U' cases should not happen normally because we don't run
any git commands if the subproject directory exists and contains
a meson build file. However, if the user accidentally messed up the
subproject checkout to a version that had no build files, we would
error out with an assertion.
Nirbheek Chauhan