[src/trunk]: src/usr.bin/make/unit-tests make(1): fix CRLF line endings in un...

[rillig <rillig%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/6c16b1729971
branches:  trunk
changeset: 976563:6c16b1729971
user:      rillig <rillig%NetBSD.org@localhost>
date:      Sun Sep 27 09:53:41 2020 +0000

description:
make(1): fix CRLF line endings in unit tests

diffstat:

 usr.bin/make/unit-tests/dep-colon-bug-cross-file.mk |   82 ++++++------
 usr.bin/make/unit-tests/varparse-undef-partial.mk   |  128 ++++++++++----------
 2 files changed, 105 insertions(+), 105 deletions(-)

diffs (218 lines):

diff -r 298e05c577aa -r 6c16b1729971 usr.bin/make/unit-tests/dep-colon-bug-cross-file.mk
--- a/usr.bin/make/unit-tests/dep-colon-bug-cross-file.mk       Sun Sep 27 01:07:12 2020 +0000
+++ b/usr.bin/make/unit-tests/dep-colon-bug-cross-file.mk       Sun Sep 27 09:53:41 2020 +0000
@@ -1,41 +1,41 @@
-# $NetBSD: dep-colon-bug-cross-file.mk,v 1.3 2020/09/25 23:42:43 rillig Exp $
-#
-# Until 2020-09-25, the very last dependency group of a top-level makefile
-# was not finished properly.  This made it possible to add further commands
-# to that target.
-#
-# In pass 1, there is a dependency group at the bottom of the file.
-# This dependency group is not finished properly.  Finishing the dependency
-# group would add the OP_HAS_COMMANDS flag to the "all" target, thereby
-# preventing any commands from being added later.
-#
-# After the file has been parsed completely, it is parsed again in pass 2.
-# In this pass, another command is added to the "current dependency group",
-# which was still the one from pass 1, which means it was possible to later
-# add commands to an existing target, even across file boundaries.
-#
-# Oops, even worse.  Running this test in a make from 2020-09-25 or earlier
-# on NetBSD 8.0 x86_64 with MALLOC_OPTIONS=JA produces this or a similar
-# output:
-#
-#      make: cannot open ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ.
-#
-# The 'Z' means access to already freed memory; see jemalloc(3).  The cause
-# for this is that in MainParseArgs, the command line arguments were not
-# properly copied before storing them in global variables.
-
-PASS?= 1
-
-.if ${PASS} == 2
-all:
-       : pass 2
-.endif
-
-.if ${PASS} == 1
-
-PASS=  2
-.MAKEFLAGS: -f ${.PARSEDIR:q}/${.PARSEFILE:q}
-
-all:
-       : pass 1
-.endif
+# $NetBSD: dep-colon-bug-cross-file.mk,v 1.4 2020/09/27 09:53:41 rillig Exp $
+#
+# Until 2020-09-25, the very last dependency group of a top-level makefile
+# was not finished properly.  This made it possible to add further commands
+# to that target.
+#
+# In pass 1, there is a dependency group at the bottom of the file.
+# This dependency group is not finished properly.  Finishing the dependency
+# group would add the OP_HAS_COMMANDS flag to the "all" target, thereby
+# preventing any commands from being added later.
+#
+# After the file has been parsed completely, it is parsed again in pass 2.
+# In this pass, another command is added to the "current dependency group",
+# which was still the one from pass 1, which means it was possible to later
+# add commands to an existing target, even across file boundaries.
+#
+# Oops, even worse.  Running this test in a make from 2020-09-25 or earlier
+# on NetBSD 8.0 x86_64 with MALLOC_OPTIONS=JA produces this or a similar
+# output:
+#
+#      make: cannot open ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ.
+#
+# The 'Z' means access to already freed memory; see jemalloc(3).  The cause
+# for this is that in MainParseArgs, the command line arguments were not
+# properly copied before storing them in global variables.
+
+PASS?= 1
+
+.if ${PASS} == 2
+all:
+       : pass 2
+.endif
+
+.if ${PASS} == 1
+
+PASS=  2
+.MAKEFLAGS: -f ${.PARSEDIR:q}/${.PARSEFILE:q}
+
+all:
+       : pass 1
+.endif
diff -r 298e05c577aa -r 6c16b1729971 usr.bin/make/unit-tests/varparse-undef-partial.mk
--- a/usr.bin/make/unit-tests/varparse-undef-partial.mk Sun Sep 27 01:07:12 2020 +0000
+++ b/usr.bin/make/unit-tests/varparse-undef-partial.mk Sun Sep 27 09:53:41 2020 +0000
@@ -1,64 +1,64 @@
-# $NetBSD: varparse-undef-partial.mk,v 1.1 2020/09/25 05:56:59 rillig Exp $
-
-# When an undefined variable is expanded in a ':=' assignment, only the
-# initial '$' of the variable expression is skipped by the parser, while
-# the remaining expression is evaluated.  In edge cases this can lead to
-# a completely different interpretation of the partially expanded text.
-
-LIST=  ${DEF} ${UNDEF} ${VAR.${PARAM}} end
-DEF=   defined
-PARAM= :Q
-
-# The expression ${VAR.{PARAM}} refers to the variable named "VAR.:Q",
-# with the ":Q" being part of the name.  This variable is not defined,
-# therefore the initial '$' of that whole expression is skipped by the
-# parser (see Var_Subst, the Buf_AddByte in the else branch) and the rest
-# of the expression is expanded as usual.
-#
-# The resulting variable expression is ${VAR.:Q}, which means that the
-# interpretation of the ":Q" has changed from being part of the variable
-# name to being a variable modifier.  This is a classical code injection.
-EVAL:= ${LIST}
-.if ${EVAL} != "defined   end"
-.  error ${EVAL}
-.endif
-
-# Define the possible outcomes, to see which of them gets expanded.
-VAR.=          var-dot without parameter
-${:UVAR.\:Q}=  var-dot with parameter :Q
-
-# At this point, the variable "VAR." is defined, therefore the expression
-# ${VAR.:Q} is expanded as usual.
-.if ${EVAL} != "defined  var-dot\\ without\\ parameter end"
-.  error ${EVAL}
-.endif
-
-# In contrast to the previous line, evaluating the original LIST again now
-# produces a different result since the ":Q" has already been inserted
-# literally into the expression.  The variable named "VAR.:Q" is defined,
-# therefore it is resolved as usual.  The ":Q" is interpreted as part of the
-# variable name, as would be expected from reading the variable expression.
-EVAL:= ${LIST}
-.if ${EVAL} != "defined  var-dot with parameter :Q end"
-.  error ${EVAL}
-.endif
-
-# It's difficult to decide what the best behavior is in this situation.
-# Should the whole expression be skipped for now, or should the inner
-# subexpressions be expanded already?
-#
-# Example 1:
-# CFLAGS:=     ${CFLAGS:N-W*} ${COPTS.${COMPILER}}
-#
-# The variable COMPILER typically contains an identifier and the variable is
-# not modified later.  In this practical case, it does not matter whether the
-# expression is expanded early, or whether the whole ${COPTS.${COMPILER}} is
-# expanded as soon as the variable COPTS.${COMPILER} becomes defined.  The
-# expression ${COMPILER} would be expanded several times, but in this simple
-# scenario there would not be any side effects.
-#
-# TODO: Add a practical example where early/lazy expansion actually makes a
-# difference.
-
-all:
-       @:
+# $NetBSD: varparse-undef-partial.mk,v 1.2 2020/09/27 09:53:41 rillig Exp $
+
+# When an undefined variable is expanded in a ':=' assignment, only the
+# initial '$' of the variable expression is skipped by the parser, while
+# the remaining expression is evaluated.  In edge cases this can lead to
+# a completely different interpretation of the partially expanded text.
+
+LIST=  ${DEF} ${UNDEF} ${VAR.${PARAM}} end
+DEF=   defined
+PARAM= :Q
+
+# The expression ${VAR.{PARAM}} refers to the variable named "VAR.:Q",
+# with the ":Q" being part of the name.  This variable is not defined,
+# therefore the initial '$' of that whole expression is skipped by the
+# parser (see Var_Subst, the Buf_AddByte in the else branch) and the rest
+# of the expression is expanded as usual.
+#
+# The resulting variable expression is ${VAR.:Q}, which means that the
+# interpretation of the ":Q" has changed from being part of the variable
+# name to being a variable modifier.  This is a classical code injection.
+EVAL:= ${LIST}
+.if ${EVAL} != "defined   end"
+.  error ${EVAL}
+.endif
+
+# Define the possible outcomes, to see which of them gets expanded.
+VAR.=          var-dot without parameter
+${:UVAR.\:Q}=  var-dot with parameter :Q
+
+# At this point, the variable "VAR." is defined, therefore the expression
+# ${VAR.:Q} is expanded as usual.
+.if ${EVAL} != "defined  var-dot\\ without\\ parameter end"
+.  error ${EVAL}
+.endif
+
+# In contrast to the previous line, evaluating the original LIST again now
+# produces a different result since the ":Q" has already been inserted
+# literally into the expression.  The variable named "VAR.:Q" is defined,
+# therefore it is resolved as usual.  The ":Q" is interpreted as part of the
+# variable name, as would be expected from reading the variable expression.
+EVAL:= ${LIST}
+.if ${EVAL} != "defined  var-dot with parameter :Q end"
+.  error ${EVAL}
+.endif
+
+# It's difficult to decide what the best behavior is in this situation.
+# Should the whole expression be skipped for now, or should the inner
+# subexpressions be expanded already?
+#
+# Example 1:
+# CFLAGS:=     ${CFLAGS:N-W*} ${COPTS.${COMPILER}}
+#
+# The variable COMPILER typically contains an identifier and the variable is
+# not modified later.  In this practical case, it does not matter whether the
+# expression is expanded early, or whether the whole ${COPTS.${COMPILER}} is
+# expanded as soon as the variable COPTS.${COMPILER} becomes defined.  The
+# expression ${COMPILER} would be expanded several times, but in this simple
+# scenario there would not be any side effects.
+#
+# TODO: Add a practical example where early/lazy expansion actually makes a
+# difference.
+
+all:
+       @: