CVS log for src/usr.bin/make/unit-tests/directive-for.exp

Up to [cvs.NetBSD.org] / src / usr.bin / make / unit-tests

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

make: reduce line length in error messages

The error messages for deeply nested parse errors were hard to decipher,
due to the large amount of text.  Split these messages into individual
lines, just as in the backtrace for .include files and .for loops.  This
unified backtrace makes the output more uniform.

tests/make: clean up tests

Prefer "expect+X" directives to be above the code generating them,
instead of "expect-X" directives below the code.

In varmod-edge.mk, separate the tests, as the common loop does not pull
its weight.

make: in error messages for anonymous variables, log the value

make: add more context information to error messages

In case of a parse error or evaluation error, print the variable value
in addition to the variable name, to see the effects of previous
expression modifiers.

In nested make calls, print the current directory at the bottom of a
stack trace, as that information is otherwise hard to get in a parallel
build spanning multiple directories.

make: provide more context information for parse/evaluate errors

tests/make: show how global variables are unaffected by .for loops

tests/make: clean up, explain and reorganize several tests

tests/make: force line-based diagnostics to be listed in the tests

This way, contradictions between the intended output and the actual
output are closer together and have a better chance of being spotted.

make: add more details to debug logging of .for loops

tests/make: clean up tests for .for loops

Most of the tests from forloop.mk were already in directive-for.mk.

make: skip syntactically wrong .for loops

When a .for loop cannot be interpreted correctly, for example when there
are no iteration variables or the number of words doesn't match the
iteration variables, skip the body of the .for loop instead of
interpreting it once.

make: disallow characters like '$' in variable names in .for loops

Fixes PR 53146.

tests/make: add more tests for unusual variable names in .for loops

make: fix parsing of unusual line continuations in .for loops

make: fix reported line numbers of continuation lines (since 2002)

Previously, multi-line directives like '.info' or '.error' reported the
line number of their last line instead of their first line, which is
more usual.  This also affected the debug log from '-dp'.

tests/make: demonstrate edge case in parsing .for loops

tests/make: test edge cases in .for loops

make: improve error message for unknown modifier

Back in 1995, the modifiers were all single-character, and it made sense
to print only the first character.  Nowadays, with ':S', ':@var@...@',
'::=' and several others, a little more context is useful to see where
the exact error is.  The actual modifier is still guessed, and the guess
may be wrong as soon as backslashes get involved, but it is still better
than before.

make(1): add test for missing error handling in .for loop

make(1): update and add comments in tests

As a result of the new comments, some line numbers have changed in the
output of the tests.  No other changes.

make(1): test funny character in .for variable names

make(1): add test for escaping parentheses and braces in .for loops

make(1): remove obsolete fix for PR bin/29985

make(1): add test for .for loop from PR bin/29985

make(1): add test for nested .for loops with the same variable name

make(1): add test for the .for directive

For a long time, I had assumed that the iteration variables of a .for
loop are just normal global variables.  This assumption was wrong but
didn't have any consequences.

The iteration variables of a .for loop can just be accessed like global
variables, therefore it is not obvious that they are implemented in a
completely different way.

There are some edge cases in conditions used inside .for loops, in which
the iteration variables cannot be used like normal variables.  An
example is brought up in https://gnats.netbsd.org/47888, which observes
that the defined() and empty() functions in conditions only work with
variables but ignore the iteration "variables", simply because these are
not variables but only expressions.