Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added warning if check kwarg of run_command is not given. #9304

Merged

Conversation

Volker-Weissmann
Copy link
Contributor

See #9300

@codecov
Copy link

codecov bot commented Sep 27, 2021

Codecov Report

Merging #9304 (4401a89) into master (32b7cbd) will decrease coverage by 3.13%.
The diff coverage is n/a.

❗ Current head 4401a89 differs from pull request most recent head d76b5e1. Consider uploading reports for the commit d76b5e1 to get more accurate results
Impacted file tree graph

@@            Coverage Diff             @@
##           master    #9304      +/-   ##
==========================================
- Coverage   67.29%   64.15%   -3.14%     
==========================================
  Files         394      198     -196     
  Lines       85344    42662   -42682     
  Branches    17465     8729    -8736     
==========================================
- Hits        57432    27371   -30061     
+ Misses      23231    12994   -10237     
+ Partials     4681     2297    -2384     
Impacted Files Coverage Δ
wrap/wraptool.py 40.80% <0.00%> (-0.72%) ⬇️
msubprojects.py 55.41% <0.00%> (-0.41%) ⬇️
dependencies/pkgconfig.py 58.44% <0.00%> (-0.31%) ⬇️
mesonlib/universal.py 75.76% <0.00%> (-0.09%) ⬇️
backend/ninjabackend.py 71.17% <0.00%> (-0.02%) ⬇️
interpreter/interpreter.py 81.58% <0.00%> (-0.01%) ⬇️
mesonbuild/scripts/scanbuild.py
mesonbuild/templates/dlangtemplates.py
mesonbuild/interpreterbase/interpreterbase.py
mesonbuild/cmake/traceparser.py
... and 156 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 32b7cbd...d76b5e1. Read the comment docs.

@@ -9,7 +9,7 @@ foo = false

executable(target_name, target_src, build_by_default : foo)

r = run_command(find_program('c_compiler.py'))
r = run_command(find_program('c_compiler.py'), check: false)
if r.returncode() != 0
error('FAILED')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one should should probably be check: true, lol

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make sure we still have at least one place where we test with check: false and a command that actually fails.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

33 run program does that several times. assert(ret.returncode() == 0, 'failed to run python3: ' + ret.stderr())

If you're looking for one that is expected to error out and raises a testsuite failure if ret.returncode() == 0, this doesn't do that either.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you run rg -F "check: false" test\ cases/, you'll find this pattern at a couple of places:

r = run_command(..., check: false)
if r.returncode() != 0
    error('some error')
endif

(sometimes with an if clause, sometimes with an assert). This can be removed if we set check to true, but this would change the error message.
In some places (like error('FAILED')), this error message isn't better than the default, but in some other places it is.
I think you should decide which places should keep their custom error messages and which places can use the default error message.

@@ -15,7 +15,7 @@ if not is_windows and build_machine.system() != 'cygwin'
# * Windows user permissions to create symlinks, and/or Windows in Developer mode
# so at this time the symlink test is skipped for Windows.
symlink = meson.current_build_dir() / 'a_symlink'
run_command('ln', '-s', meson.current_source_dir() / 'meson.build', symlink)
run_command('ln', '-s', meson.current_source_dir() / 'meson.build', symlink, check: true)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great error right here!

The test runner configures this test case correctly, and it succeeds in generating, running, and in theory passing. But the test runner also checks that the backend will correctly force regeneration for build/test, by updating the utime of meson.build.

On this second run, the ln program fails because

--- stderr ---
/usr/bin/ln: failed to create symbolic link '/tmp/b d19af95f3b/a_symlink': File exists

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(after your latest push)

Note that the additional -f flag to ln would make it overwrite the existing symlink rather than erroring.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@eli-schwartz
Copy link
Member

Meson PRs cannot include merge commits. Please rebase instead.

Also the "simple bug fix" commit should be squashed into the commit which it is fixing.

@Volker-Weissmann Volker-Weissmann force-pushed the check_false_warning branch 2 times, most recently from e78ef72 to 74cd845 Compare October 10, 2021 19:57
@Volker-Weissmann
Copy link
Contributor Author

Meson PRs cannot include merge commits. Please rebase instead.

Also the "simple bug fix" commit should be squashed into the commit which it is fixing.

I fought with git for a while and ended up saving a code-diff elsewhere, deleting my local repo, and force-pushing a commit created from the code-diff.

Relevant xkcd: https://xkcd.com/1597/

@eli-schwartz
Copy link
Member

That sounds complicated... I'd just git branch newbranch origin/master and apply the code diff to that, and then force push. No need to delete the repo.

Anyway, changes seem okay, let's see what CI thinks.

@Volker-Weissmann
Copy link
Contributor Author

That sounds complicated... I'd just git branch newbranch origin/master and apply the code diff to that, and then force push. No need to delete the repo.

Then I would have to create a new PR, because this PR wants to merge check_false_warning and not newbranch

@eli-schwartz
Copy link
Member

Oh! Almost forgot... sorry...

This should get a release notes snippet in docs/markdown/snippets/.

@eli-schwartz
Copy link
Member

Nah, you can push branches like this:

git push myfork <currentbranch>:<remotebranch>

Or actually, it's a good point that you could/should also set --set-upstream-to=myfork/check_false_warning.

@Volker-Weissmann
Copy link
Contributor Author

Oh! Almost forgot... sorry...

This should get a release notes snippet in docs/markdown/snippets/.

Done

@eli-schwartz
Copy link
Member

# This test only checks that the compiler object can be passed to
# run_command(). If the compiler has been launched, it is expected
# to output something either to stdout or to stderr.
result = run_command(cc, '--version')
if result.stdout() == '' and result.stderr() == ''
error('No output in stdout and stderr. Did the compiler run at all?')
endif

Fails on Windows with:

--- stderr ---
Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27045 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

cl : Command line warning D9002 : ignoring unknown option '--version'
cl : Command line error D8003 : missing source filename



test cases\unit\24 compiler run_command\meson.build:7:0: ERROR: Command "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.16.27023\bin\HostX86\x86\cl.EXE --version" failed with status 2.

This case should be check: false as we don't care about the return value.

@Volker-Weissmann
Copy link
Contributor Author

This case should be check: false as we don't care about the return value.

Done

@eli-schwartz eli-schwartz added this to the 0.61.0 milestone Oct 13, 2021
@eli-schwartz
Copy link
Member

if result.stdout() == '' and result.stderr() == ''
  error('No output in stdout and stderr. Did the compiler run at all?')
endif

We do care about this, please don't remove it. :)

@Volker-Weissmann
Copy link
Contributor Author

if result.stdout() == '' and result.stderr() == ''
  error('No output in stdout and stderr. Did the compiler run at all?')
endif

We do care about this, please don't remove it. :)

Oops, my fault, fixed.

@eli-schwartz
Copy link
Member

Alright, thanks. This seems good to me, so it should be merged as soon as the release candidate freeze ends.

@eli-schwartz eli-schwartz merged commit 2c079d8 into mesonbuild:master Oct 31, 2021
@eli-schwartz
Copy link
Member

Thanks!

libvirtmirror pushed a commit to libvirt/libvirt that referenced this pull request Jan 24, 2022
An update to meson 0.61.1 meant that it started showing warnings due to the fact
that the default for run_command's 'check' parameter is going to change.  It
unveiled the fact that we were even missing that parameter in some calls where
we expected different outcome.  To make sure the behaviour does not change
specify the parameter explicitly.  In places where we check for the return code
the parameter should be 'false' so that meson does not fail.  In all other cases
the parameter should be set to 'true' to make sure possible failure also stops
meson.

The warning in meson was added in mesonbuild/meson#9304

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants