Home | History | Annotate | Line # | Download | only in unit-tests
varmod-loop.mk revision 1.11
      1 # $NetBSD: varmod-loop.mk,v 1.11 2021/03/15 12:15:03 rillig Exp $
      2 #
      3 # Tests for the :@var (a] ...${var}...@ variable modifier.
      4 
      5 .MAKE.SAVE_DOLLARS=	yes
      6 
      7 all: mod-loop-varname
      8 all: mod-loop-resolve
      9 all: mod-loop-varname-dollar
     10 all: mod-loop-dollar
     11 
     12 # In the :@ modifier, the name of the loop variable can even be generated
     13 # dynamically.  There's no practical use-case for this, and hopefully nobody
     14 # will ever depend on this, but technically it's possible.
     15 # Therefore, in -dL mode, this is forbidden, see lint.mk.
     16 mod-loop-varname:
     17 	@echo :${:Uone two three:@${:Ubar:S,b,v,}@+${var}+@:Q}:
     18 
     19 	# ":::" is a very creative variable name, unlikely in practice.
     20 	# The expression ${\:\:\:} would not work since backslashes can only
     21 	# be escaped in the modifiers, but not in the variable name.
     22 	@echo :${:U1 2 3:@:::@x${${:U\:\:\:}}y@}:
     23 
     24 	# "@@" is another creative variable name.
     25 	@echo :${:U1 2 3:@\@\@@x${@@}y@}:
     26 
     27 	# Even "@" works as a variable name since the variable is installed
     28 	# in the "current" scope, which in this case is the one from the
     29 	# target.
     30 	@echo :$@: :${:U1 2 3:@\@@x${@}y@}: :$@:
     31 
     32 	# In extreme cases, even the backslash can be used as variable name.
     33 	# It needs to be doubled though.
     34 	@echo :${:U1 2 3:@\\@x${${:Ux:S,x,\\,}}y@}:
     35 
     36 	# The variable name can technically be empty, and in this situation
     37 	# the variable value cannot be accessed since the empty "variable"
     38 	# is protected to always return an empty string.
     39 	@echo empty: :${:U1 2 3:@@x${}y@}:
     40 
     41 
     42 # The :@ modifier resolves the variables from the replacement text once more
     43 # than expected.  In particular, it resolves _all_ variables from the scope,
     44 # and not only the loop variable (in this case v).
     45 SRCS=		source
     46 CFLAGS.source=	before
     47 ALL_CFLAGS:=	${SRCS:@src@${CFLAGS.${src}}@}	# note the ':='
     48 CFLAGS.source+=	after
     49 .if ${ALL_CFLAGS} != "before"
     50 .  error
     51 .endif
     52 
     53 
     54 # In the following example, the modifier ':@' expands the '$$' to '$'.  This
     55 # means that when the resulting expression is evaluated, these resulting '$'
     56 # will be interpreted as starting a subexpression.
     57 #
     58 # The d means direct reference, the i means indirect reference.
     59 RESOLVE=	${RES1} $${RES1}
     60 RES1=		1d${RES2} 1i$${RES2}
     61 RES2=		2d${RES3} 2i$${RES3}
     62 RES3=		3
     63 
     64 # TODO: convert to '.if'.
     65 mod-loop-resolve:
     66 	@echo $@:${RESOLVE:@v@w${v}w@:Q}:
     67 
     68 
     69 # Until 2020-07-20, the variable name of the :@ modifier could end with one
     70 # or two dollar signs, which were silently ignored.
     71 # There's no point in allowing a dollar sign in that position.
     72 mod-loop-varname-dollar:
     73 	@echo $@:${1 2 3:L:@v$@($v)@:Q}.
     74 	@echo $@:${1 2 3:L:@v$$@($v)@:Q}.
     75 	@echo $@:${1 2 3:L:@v$$$@($v)@:Q}.
     76 
     77 # Demonstrate that it is possible to generate dollar signs using the
     78 # :@ modifier.
     79 #
     80 # These are edge cases that could have resulted in a parse error as well
     81 # since the $@ at the end could have been interpreted as a variable, which
     82 # would mean a missing closing @ delimiter.
     83 mod-loop-dollar:
     84 	@echo $@:${:U1:@word@${word}$@:Q}:
     85 	@echo $@:${:U2:@word@$${word}$$@:Q}:
     86 	@echo $@:${:U3:@word@$$${word}$$$@:Q}:
     87 	@echo $@:${:U4:@word@$$$${word}$$$$@:Q}:
     88 	@echo $@:${:U5:@word@$$$$${word}$$$$$@:Q}:
     89 	@echo $@:${:U6:@word@$$$$$${word}$$$$$$@:Q}:
     90 
     91 # It may happen that there are nested :@ modifiers that use the same name for
     92 # for the loop variable.  These modifiers influence each other.
     93 #
     94 # As of 2020-10-18, the :@ modifier is implemented by actually setting a
     95 # variable in the scope of the expression and deleting it again after the
     96 # loop.  This is different from the .for loops, which substitute the variable
     97 # expression with ${:Uvalue}, leading to different unwanted side effects.
     98 #
     99 # To make the behavior more predictable, the :@ modifier should restore the
    100 # loop variable to the value it had before the loop.  This would result in
    101 # the string "1a b c1 2a b c2 3a b c3", making the two loops independent.
    102 .if ${:U1 2 3:@i@$i${:Ua b c:@i@$i@}${i:Uu}@} != "1a b cu 2a b cu 3a b cu"
    103 .  error
    104 .endif
    105 
    106 # During the loop, the variable is actually defined and nonempty.
    107 # If the loop were implemented in the same way as the .for loop, the variable
    108 # would be neither defined nor nonempty since all expressions of the form
    109 # ${var} would have been replaced with ${:Uword} before evaluating them.
    110 .if defined(var)
    111 .  error
    112 .endif
    113 .if ${:Uword:@var@${defined(var):?def:undef} ${empty(var):?empty:nonempty}@} \
    114     != "def nonempty"
    115 .  error
    116 .endif
    117 .if defined(var)
    118 .  error
    119 .endif
    120 
    121 # Assignment using the ':=' operator, combined with the :@var@ modifier
    122 #
    123 8_DOLLARS=	$$$$$$$$
    124 # This string literal is written with 8 dollars, and this is saved as the
    125 # variable value.  But as soon as this value is evaluated, it goes through
    126 # Var_Subst, which replaces each '$$' with a single '$'.  This could be
    127 # prevented by VarEvalFlags.keepDollar, but that flag is usually removed
    128 # before expanding subexpressions.  See ApplyModifier_Loop and
    129 # ParseModifierPart for examples.
    130 #
    131 .MAKEFLAGS: -dcp
    132 USE_8_DOLLARS=	${:U1:@var@${8_DOLLARS}@} ${8_DOLLARS} $$$$$$$$
    133 .if ${USE_8_DOLLARS} != "\$\$\$\$ \$\$\$\$ \$\$\$\$"
    134 .  error
    135 .endif
    136 #
    137 SUBST_CONTAINING_LOOP:= ${USE_8_DOLLARS}
    138 # The ':=' assignment operator evaluates the variable value using the mode
    139 # VARE_KEEP_DOLLAR_UNDEF, which means that some dollar signs are preserved,
    140 # but not all.  The dollar signs in the top-level expression and in the
    141 # indirect ${8_DOLLARS} are preserved.
    142 #
    143 # The variable modifier :@var@ does not preserve the dollar signs though, no
    144 # matter in which context it is evaluated.  What happens in detail is:
    145 # First, the modifier part "${8_DOLLARS}" is parsed without expanding it.
    146 # Next, each word of the value is expanded on its own, and at this moment
    147 # in ApplyModifier_Loop, the flag keepDollar is not passed down to
    148 # ModifyWords, resulting in "$$$$" for the first word of USE_8_DOLLARS.
    149 #
    150 # The remaining words of USE_8_DOLLARS are not affected by any variable
    151 # modifier and are thus expanded with the flag keepDollar in action.
    152 # The variable SUBST_CONTAINING_LOOP therefore gets assigned the raw value
    153 # "$$$$ $$$$$$$$ $$$$$$$$".
    154 #
    155 # The variable expression in the condition then expands this raw stored value
    156 # once, resulting in "$$ $$$$ $$$$".  The effects from VARE_KEEP_DOLLAR no
    157 # longer take place since they had only been active during the evaluation of
    158 # the variable assignment.
    159 .if ${SUBST_CONTAINING_LOOP} != "\$\$ \$\$\$\$ \$\$\$\$"
    160 .  error
    161 .endif
    162 .MAKEFLAGS: -d0
    163 
    164 # After looping over the words of the expression, the loop variable gets
    165 # undefined.  The modifier ':@' uses an ordinary global variable for this,
    166 # which is different from the '.for' loop, which replaces ${var} with
    167 # ${:Uvalue} in the body of the loop.  This choice of implementation detail
    168 # can be used for a nasty side effect.  The expression ${:U:@VAR@@} evaluates
    169 # to an empty string, plus it undefines the variable 'VAR'.  This is the only
    170 # possibility to undefine a global variable during evaluation.
    171 GLOBAL=		before-global
    172 RESULT:=	${:U${GLOBAL} ${:U:@GLOBAL@@} ${GLOBAL:Uundefined}}
    173 .if ${RESULT} != "before-global  undefined"
    174 .  error
    175 .endif
    176 
    177 # The above side effect of undefining a variable from a certain scope can be
    178 # further combined with the otherwise undocumented implementation detail that
    179 # the argument of an '.if' directive is evaluated in cmdline scope.  Putting
    180 # these together makes it possible to undefine variables from the cmdline
    181 # scope, something that is not possible in a straight-forward way.
    182 .MAKEFLAGS: CMDLINE=cmdline
    183 .if ${:U${CMDLINE}${:U:@CMDLINE@@}} != "cmdline"
    184 .  error
    185 .endif
    186 # Now the cmdline variable got undefined.
    187 .if ${CMDLINE} != "cmdline"
    188 .  error
    189 .endif
    190 # At this point, it still looks as if the cmdline variable were defined,
    191 # since the value of CMDLINE is still "cmdline".  That impression is only
    192 # superficial though, the cmdline variable is actually deleted.  To
    193 # demonstrate this, it is now possible to override its value using a global
    194 # variable, something that was not possible before:
    195 CMDLINE=	global
    196 .if ${CMDLINE} != "global"
    197 .  error
    198 .endif
    199 # Now undefine that global variable again, to get back to the original value.
    200 .undef CMDLINE
    201 .if ${CMDLINE} != "cmdline"
    202 .  error
    203 .endif
    204 # What actually happened is that when CMDLINE was set by the '.MAKEFLAGS'
    205 # target in the cmdline scope, that same variable was exported to the
    206 # environment, see Var_SetWithFlags.
    207 .unexport CMDLINE
    208 .if ${CMDLINE} != "cmdline"
    209 .  error
    210 .endif
    211 # The above '.unexport' has no effect since UnexportVar requires a global
    212 # variable of the same name to be defined, otherwise nothing is unexported.
    213 CMDLINE=	global
    214 .unexport CMDLINE
    215 .undef CMDLINE
    216 .if ${CMDLINE} != "cmdline"
    217 .  error
    218 .endif
    219 # This still didn't work since there must not only be a global variable, the
    220 # variable must be marked as exported as well, which it wasn't before.
    221 CMDLINE=	global
    222 .export CMDLINE
    223 .unexport CMDLINE
    224 .undef CMDLINE
    225 .if ${CMDLINE:Uundefined} != "undefined"
    226 .  error
    227 .endif
    228 # Finally the variable 'CMDLINE' from the cmdline scope is gone, and all its
    229 # traces from the environment are gone as well.  To do that, a global variable
    230 # had to be defined and exported, something that is far from obvious.  To
    231 # recap, here is the essence of the above story:
    232 .MAKEFLAGS: CMDLINE=cmdline	# have a cmdline + environment variable
    233 .if ${:U:@CMDLINE@@}}		# undefine cmdline, keep environment
    234 .endif
    235 CMDLINE=	global		# needed for deleting the environment
    236 .export CMDLINE			# needed for deleting the environment
    237 .unexport CMDLINE		# delete the environment
    238 .undef CMDLINE			# delete the global helper variable
    239 .if ${CMDLINE:Uundefined} != "undefined"
    240 .  error			# 'CMDLINE' is gone now from all scopes
    241 .endif
    242 
    243 
    244 # TODO: Actually trigger the undefined behavior (use after free) that was
    245 #  already suspected in Var_Parse, in the comment 'the value of the variable
    246 #  must not change'.
    247