| History log of /src/usr.bin/make/unit-tests/var-eval-short.exp |
| Revision | | Date | Author | Comments |
| 1.34 |
| 30-Mar-2025 |
rillig | make: use '"filename" line 123' for locations instead of 'filename:123'
The format 'filename:123' is commonly used for identifying a location in
a file. Text editors recognize it and allow quick navigation through it.
The previous format was specific to make and would have required custom
support in editors.
The new format was already used in stack traces, except for the first
line. Now all lines use the same format.
|
| 1.33 |
| 11-Jan-2025 |
rillig | make: omit redundant follow-up message "Malformed conditional"
If there is a parse error or an evaluation error during the conditional,
the conditional is already mentioned in the "while evaluating condition"
line, so there's no reason to repeat it once again.
Same for the "Bad condition" message from the '?:' modifier.
|
| 1.32 |
| 31-Oct-2024 |
rillig | 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.
|
| 1.31 |
| 29-Aug-2024 |
rillig | 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.
|
| 1.30 |
| 06-Aug-2024 |
rillig | make: in error message about conditionals, use single quotes
Single quotes are used less often in the conditionals themselves, which
leads to fewer confusions.
|
| 1.29 |
| 05-Jul-2024 |
rillig | make: in error messages, distinguish parsing from evaluating
|
| 1.28 |
| 05-Jul-2024 |
rillig | make: in error messages for anonymous variables, log the value
|
| 1.27 |
| 04-Jul-2024 |
rillig | make: on error, print the targets to be made
This helps to understand situations with several nested sub-makes in
varying directories.
|
| 1.26 |
| 02-Jun-2024 |
rillig | branches: 1.26.2;
make: sync VarEvalMode constant names with their debug log names
|
| 1.25 |
| 20-Apr-2024 |
rillig | make: provide more context information for parse/evaluate errors
|
| 1.24 |
| 14-Apr-2024 |
rillig | make: add debug logging for .if and .for lines in -dp mode
This helps track down in which line a condition is evaluated.
|
| 1.23 |
| 01-Jun-2023 |
rillig | 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.
|
| 1.22 |
| 09-May-2023 |
rillig | 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.
|
| 1.21 |
| 18-Feb-2023 |
rillig | 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.
|
| 1.20 |
| 23-Aug-2022 |
rillig | 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.
|
| 1.19 |
| 08-Aug-2022 |
rillig | make: fix parsing of modifiers containing unbalanced subexpressions
|
| 1.18 |
| 28-Dec-2021 |
rillig | 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.
|
| 1.17 |
| 27-Dec-2021 |
rillig | make: clean up comments
|
| 1.16 |
| 09-Dec-2021 |
rillig | 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".
|
| 1.15 |
| 09-Dec-2021 |
rillig | 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.
|
| 1.14 |
| 07-Sep-2021 |
rillig | tests/make: expand on the history of unnecessary evaluation
|
| 1.13 |
| 05-Apr-2021 |
rillig | 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.
|
| 1.12 |
| 05-Apr-2021 |
rillig | 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.
|
| 1.11 |
| 04-Apr-2021 |
rillig | 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.
|
| 1.10 |
| 04-Apr-2021 |
rillig | make: remove filler word 'Do' from function names for parsing
No functional change, except for debug logging.
|
| 1.9 |
| 03-Apr-2021 |
rillig | 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.
|
| 1.8 |
| 15-Mar-2021 |
rillig | 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.
|
| 1.7 |
| 14-Mar-2021 |
rillig | tests/make: document today's bug fixes in the test
|
| 1.6 |
| 14-Mar-2021 |
rillig | 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.
|
| 1.5 |
| 14-Mar-2021 |
rillig | make: do not return unevaluated 'else' part from the ':?' modifier
No functional change outside debug mode.
|
| 1.4 |
| 14-Mar-2021 |
rillig | 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.
|
| 1.3 |
| 14-Mar-2021 |
rillig | 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.
|
| 1.2 |
| 14-Mar-2021 |
rillig | 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.
|
| 1.1 |
| 14-Mar-2021 |
rillig | tests/make: add test for short-circuit evaluation of modifiers
|
| 1.26.2.1 |
| 02-Aug-2025 |
perseant | Sync with HEAD
|
