If redo searched all the way up to /default.do, it would run ./default.do instead.

This only happened if the containing project was buggy, ie. you tried
to build a target that has no .do file available anywhere. However, it
resulted in a confusing outcome for that case, where we'd run the wrong
default.do file with the wrong parameters.

Extended an existing test to catch this mistake.
This commit is contained in:
Avery Pennarun 2019-03-02 02:53:02 -05:00
commit e5a27f04e8
4 changed files with 18 additions and 4 deletions

View file

@ -1,7 +1,6 @@
rm -f x/shouldfail
log=$PWD/$1.log
rm -f "$log"
expect_fail() {
local rv=$1
@ -15,8 +14,19 @@ expect_fail() {
fi
}
# These should all fail because there is no matching .do file.
# In previous versions of redo, it would accidentally try to use
# $PWD/default.do even for ../path/file, which is incorrect. That
# could cause it to return success accidentally.
rm -f "$log"
cd inner
expect_fail 11 redo ../x/shouldfail # should fail
expect_fail 12 redo-ifchange ../x/shouldfail # should fail again
expect_fail 11 redo ../x/shouldfail
expect_fail 12 redo-ifchange ../x/shouldfail
rm -f "$log"
cd ../inner2
expect_fail 21 redo ../x/shouldfail2
expect_fail 22 redo-ifchange ../x/shouldfail2
exit 0