The NetBSD Project

CVS log for src/usr.bin/make/unit-tests/var-eval-short.exp

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

Request diff between arbitrary revisions


Default branch: MAIN


Revision 1.23 / (download) - annotate - [select for diffs], Thu Jun 1 20:56:35 2023 UTC (8 months, 4 weeks ago) by rillig
Branch: MAIN
CVS Tags: HEAD
Changes since 1.22: +4 -4 lines
Diff to previous 1.22 (colored)

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.

Revision 1.22 / (download) - annotate - [select for diffs], Tue May 9 16:27:00 2023 UTC (9 months, 3 weeks ago) by rillig
Branch: MAIN
Changes since 1.21: +2 -6 lines
Diff to previous 1.21 (colored)

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.

Revision 1.21 / (download) - annotate - [select for diffs], Sat Feb 18 11:16:09 2023 UTC (12 months, 1 week ago) by rillig
Branch: MAIN
Changes since 1.20: +4 -0 lines
Diff to previous 1.20 (colored)

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.

Revision 1.20 / (download) - annotate - [select for diffs], Tue Aug 23 19:22:01 2022 UTC (18 months, 1 week ago) by rillig
Branch: MAIN
CVS Tags: netbsd-10-base, netbsd-10-0-RC5, netbsd-10-0-RC4, netbsd-10-0-RC3, netbsd-10-0-RC2, netbsd-10-0-RC1, netbsd-10
Changes since 1.19: +0 -4 lines
Diff to previous 1.19 (colored)

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.

Revision 1.19 / (download) - annotate - [select for diffs], Mon Aug 8 18:23:30 2022 UTC (18 months, 3 weeks ago) by rillig
Branch: MAIN
Changes since 1.18: +4 -0 lines
Diff to previous 1.18 (colored)

make: fix parsing of modifiers containing unbalanced subexpressions

Revision 1.18 / (download) - annotate - [select for diffs], Tue Dec 28 15:49:00 2021 UTC (2 years, 2 months ago) by rillig
Branch: MAIN
Changes since 1.17: +2 -2 lines
Diff to previous 1.17 (colored)

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.

Revision 1.17 / (download) - annotate - [select for diffs], Mon Dec 27 18:54:19 2021 UTC (2 years, 2 months ago) by rillig
Branch: MAIN
Changes since 1.16: +8 -8 lines
Diff to previous 1.16 (colored)

make: clean up comments

Revision 1.16 / (download) - annotate - [select for diffs], Thu Dec 9 20:27:01 2021 UTC (2 years, 2 months ago) by rillig
Branch: MAIN
Changes since 1.15: +2 -2 lines
Diff to previous 1.15 (colored)

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".

Revision 1.15 / (download) - annotate - [select for diffs], Thu Dec 9 20:13:10 2021 UTC (2 years, 2 months ago) by rillig
Branch: MAIN
Changes since 1.14: +1 -1 lines
Diff to previous 1.14 (colored)

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.

Revision 1.14 / (download) - annotate - [select for diffs], Tue Sep 7 20:41:58 2021 UTC (2 years, 5 months ago) by rillig
Branch: MAIN
Changes since 1.13: +6 -6 lines
Diff to previous 1.13 (colored)

tests/make: expand on the history of unnecessary evaluation

Revision 1.13 / (download) - annotate - [select for diffs], Mon Apr 5 13:35:41 2021 UTC (2 years, 10 months ago) by rillig
Branch: MAIN
CVS Tags: cjep_sun2x-base1, cjep_sun2x-base, cjep_sun2x, cjep_staticlib_x-base1, cjep_staticlib_x-base, cjep_staticlib_x
Changes since 1.12: +3 -3 lines
Diff to previous 1.12 (colored)

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.

Revision 1.12 / (download) - annotate - [select for diffs], Mon Apr 5 13:14:55 2021 UTC (2 years, 10 months ago) by rillig
Branch: MAIN
Changes since 1.11: +3 -3 lines
Diff to previous 1.11 (colored)

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.

Revision 1.11 / (download) - annotate - [select for diffs], Sun Apr 4 13:35:26 2021 UTC (2 years, 10 months ago) by rillig
Branch: MAIN
Changes since 1.10: +8 -6 lines
Diff to previous 1.10 (colored)

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.

Revision 1.10 / (download) - annotate - [select for diffs], Sun Apr 4 10:13:09 2021 UTC (2 years, 10 months ago) by rillig
Branch: MAIN
Changes since 1.9: +1 -1 lines
Diff to previous 1.9 (colored)

make: remove filler word 'Do' from function names for parsing

No functional change, except for debug logging.

Revision 1.9 / (download) - annotate - [select for diffs], Sat Apr 3 22:02:59 2021 UTC (2 years, 10 months ago) by rillig
Branch: MAIN
Changes since 1.8: +6 -6 lines
Diff to previous 1.8 (colored)

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.

Revision 1.8 / (download) - annotate - [select for diffs], Mon Mar 15 15:39:13 2021 UTC (2 years, 11 months ago) by rillig
Branch: MAIN
Changes since 1.7: +8 -8 lines
Diff to previous 1.7 (colored)

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.

Revision 1.7 / (download) - annotate - [select for diffs], Sun Mar 14 20:41:39 2021 UTC (2 years, 11 months ago) by rillig
Branch: MAIN
Changes since 1.6: +5 -5 lines
Diff to previous 1.6 (colored)

tests/make: document today's bug fixes in the test

Revision 1.6 / (download) - annotate - [select for diffs], Sun Mar 14 19:29:37 2021 UTC (2 years, 11 months ago) by rillig
Branch: MAIN
Changes since 1.5: +0 -2 lines
Diff to previous 1.5 (colored)

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.

Revision 1.5 / (download) - annotate - [select for diffs], Sun Mar 14 19:21:28 2021 UTC (2 years, 11 months ago) by rillig
Branch: MAIN
Changes since 1.4: +4 -4 lines
Diff to previous 1.4 (colored)

make: do not return unevaluated 'else' part from the ':?' modifier

No functional change outside debug mode.

Revision 1.4 / (download) - annotate - [select for diffs], Sun Mar 14 19:16:41 2021 UTC (2 years, 11 months ago) by rillig
Branch: MAIN
Changes since 1.3: +20 -0 lines
Diff to previous 1.3 (colored)

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.

Revision 1.3 / (download) - annotate - [select for diffs], Sun Mar 14 18:02:44 2021 UTC (2 years, 11 months ago) by rillig
Branch: MAIN
Changes since 1.2: +0 -1 lines
Diff to previous 1.2 (colored)

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.

Revision 1.2 / (download) - annotate - [select for diffs], Sun Mar 14 16:43:30 2021 UTC (2 years, 11 months ago) by rillig
Branch: MAIN
Changes since 1.1: +0 -1 lines
Diff to previous 1.1 (colored)

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.

Revision 1.1 / (download) - annotate - [select for diffs], Sun Mar 14 11:49:37 2021 UTC (2 years, 11 months ago) by rillig
Branch: MAIN

tests/make: add test for short-circuit evaluation of modifiers

This form allows you to request diff's between any two revisions of a file. You may select a symbolic revision name using the selection box or you may type in a numeric name using the type-in text box.




CVSweb <webmaster@jp.NetBSD.org>