Up to [cvs.NetBSD.org] / src / usr.bin / make / unit-tests
Request diff between arbitrary revisions
Keyword substitution: kv
Default branch: MAIN
make: in the debug log, always qualify line number with filename Previously, to find out the filename corresponding to a line number from a 'Parsing' line, it was necessary to find the preceding 'SetFilenameVars' line, which was unnecessarily time-consuming and distracting. The 'filename:line' format matches the one used in PrintStackTrace, and it differs from the one used in PrintLocation, as the former format is more common in other tools. Most of the affected unit tests only use the 'Parsing' lines to give additional context to their debug log, so no structural changes there.
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.
make: in error message about conditionals, use single quotes Single quotes are used less often in the conditionals themselves, which leads to fewer confusions.
make: in error messages, distinguish parsing from evaluating
make: in error messages for anonymous variables, log the value
make: on error, print the targets to be made This helps to understand situations with several nested sub-makes in varying directories.
make: sync VarEvalMode constant names with their debug log names
make: provide more context information for parse/evaluate errors
make: add debug logging for .if and .for lines in -dp mode This helps track down in which line a condition is evaluated.
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: allow ':gmtime' and ':localtime' with dynamic argument This allows ${%Y:L:gmtime=${mtime}} instead of the indirect ${%Y:L:${:Ugmtime=${mtime}}}. The direct form also prevents any ':' from the nested expression to be interpreted as a separator, which doesn't matter for the ':gmtime' and ':localtime' modifiers but will prove useful for other modifiers that follow the same pattern.
make: fix parsing of unevaluated subexpressions with unbalanced '{}' Since var.c 1.323 from 2020-07-26, modifiers containing unbalanced braces or parentheses were parsed differently, depending on whether they were relevant or not. For example, the expression '${VAR:...}' is enclosed with braces. When this expression has a modifier ':S,},}},g' that would double each '}' in that expression, the parser got confused: If the expression was relevant, the modifier was parsed as usual, taking into account that the 3 '}' in the modifier are ordinary characters. If the expression was irrelevant, the parser only counted the '{' and the '}', without taking into account that a '}' might be escaped by a '\' or be an ordinary character. Parsing therefore stopped at the first '}', assuming it would finish the expression '${VAR:S,}'. This parsing mode of only counting balanced '{' and '}' makes sense for the modifier ':@var@...@', which expands each word of the expression using the template from the '...'. These templates tend to be simple enough that counting the '{' and '}' suffices.
make: revert parsing of modifier parts (since 2022-08-08) The modifier ':@var@body@' parses the body in parse-only mode and later uses Var_Subst on it, in which each literal '$' must be written as '$$'. Trying to parse the loop body using Var_Parse treated the text '$${var:-0}' as a single '$' followed by the expression '${var:-0}', wrongly complaining about the 'Unknown modifier "-0"'. Found by sjg.
make: fix parsing of modifiers containing unbalanced subexpressions
make: make debug logging a bit more human-friendly The previous log format "ParseReadLine (%d): '%s'" focused on the implementation, it was not immediately obvious to a casual reader that the number in parentheses was the line number. Additionally, having both a colon and quotes in a log message is uncommon. The quotes have been added in parse.c 1.127 from 2007-01-01. The new log format "Parsing line %d: %s" is meant to be easier readable by humans. The quotes are not needed since ParseReadLine always strips trailing whitespace, leaving no room for ambiguities. The other log messages follow common punctuation rules, which makes the beginning of the line equally unambiguous. Before var.c 1.911 from 2021-04-05, variable assignments were logged with the format "%s:%s = %s", without a space after the colon.
make: clean up comments
make: in parse errors, mark whitespace more clearly This prevents any trailing whitespace from going unnoticed. It also marks leading whitespace more clearly, as in the examples with the time value " 1".
make: remove period from end of error messages and warnings The majority of the existing error messages and warnings does not include a period at the end. Follow this style consistently.
tests/make: expand on the history of unnecessary evaluation
make: in debug log, add space between scope and variable name Without this space, the debug log looked more like line noise, even though the only punctuation was a single innocent ':'. From a make user's perspective, the variable name is a word of its own and should not be visually glued to its namespace.
make: be more verbose in -dv debug logging The previous log output was too brief to be understandable. Give more hints by describing each part of the expression when evaluating a modifier. Distinguish between parse-only mode and eval mode since in parse-only mode most of the details are irrelevant.
make: disallow '$' in the variable name of the modifier ':@' If this restriction should break any existing makefile, the author of that makefile was probably heading for the IOMCC.
make: remove filler word 'Do' from function names for parsing No functional change, except for debug logging.
make: remove VarFlags from debug logging Before the introduction of ExprDefined, VarFlags contained whether the expression was defined or not, which was useful to know since the final value of the expression depends on this information. The other VarFlags do not influence the evaluation, so there is no point logging them.
make: change debug log for variable evaluation flags to lowercase This makes them easier distinguishable from variable names since the latter are usually uppercase. No functional change outside debug mode.
tests/make: document today's bug fixes in the test
make: do not evaluate modifier ':[...]' in parse-only mode In parse-only mode, variable expressions in the argument to that modifier are not resolved. This led to the error message about the 'Bad modifier' in var-eval-short.mk.
make: do not return unevaluated 'else' part from the ':?' modifier No functional change outside debug mode.
tests/make: add test for the ':?' modifier in parse-only mode The debug output for this scenario will change a bit in an upcoming commit, but that will not affect anything outside the debug log.
make: only evaluate the ':@' modifier if the result is actually used The test 'var-eval-short' had produced the output 'unexpected' before, on stderr. It had been generated by '${:Uword:@${FAIL}@expr@}' by combining the following obscure "features" of make: 1. the ':@' modifier loops over the words of the variable. This modifier is not really obscure, it still takes some time to get used to it. 2. the ':@' modifier allows a '$' sign in the variable name, which is useless in practice. 3. the ':@' modifier creates a temporary loop variable in the global namespace. Luckily there are only few collisions with other variable names since their naming conventions differ. 4. after looping over the words of the expression, the temporary global loop variable is deleted, and at that point the '$' is expanded, being interpreted as the start of a variable expression. 5. The ':@' modifier deleted the global variable even when it was called in parse-only mode (without VARE_WANTRES). When the modifier ':@' was initially added to make in var.c 1.40 from 2000-04-29, Var_Delete didn't expand the variable name. That feature was added in var.c 1.174 from 2013-05-18, probably without thinking of this very edge-casey combination of features. This commit fixes item 5 from the above list. The other obscurities remain for now.
make: only evaluate the ':_' modifier if the expression is needed See var-eval-short.mk:46 for the test demonstrating this change. Previously, the expression ${:Uword:_=VAR} was evaluated including all its side effects even though it was in an irrelevant branch of the condition.
tests/make: add test for short-circuit evaluation of modifiers