1# $NetBSD: varmod-ifelse.mk,v 1.41 2025/06/29 11:27:21 rillig Exp $ 2# 3# Tests for the ${cond:?then:else} variable modifier, which evaluates either 4# the then-expression or the else-expression, depending on the condition. 5# 6# The modifier was added on 1998-04-01. 7# 8# Until 2015-10-11, the modifier always evaluated both the "then" and the 9# "else" expressions. 10 11# TODO: Implementation 12 13# The variable name of the expression is expanded and then taken as the 14# condition. In the below example it becomes: 15# 16# bare words == "literal" 17# 18# This confuses the parser, which expects an operator instead of the bare 19# word "expression". If the name were expanded lazily, everything would be 20# fine since the condition would be: 21# 22# ${:Ubare words} == "literal" 23# 24# Evaluating the variable name lazily would require additional code in 25# Var_Parse and ParseVarname, it would be more useful and predictable 26# though. 27# expect+1: Bad condition 28.if ${${:Ubare words} == "literal":?bad:bad} 29. error 30.else 31. error 32.endif 33 34# In a variable assignment, undefined variables are not an error. 35# Because of the early expansion, the whole condition evaluates to 36# ' == ""' though, which cannot be parsed because the left-hand side looks 37# empty. 38# expect+1: Bad condition 39COND:= ${${UNDEF} == "":?bad-assign:bad-assign} 40 41# In a conditional directive, undefined variables are reported as such. In a 42# ':?' modifier, though, the "variable name" is expanded first, and in that 43# context, an undefined expression is not an error. The "variable name" then 44# becomes the condition, in this case ' == ""', which is malformed because the 45# left-hand side looks empty. 46# expect+1: Bad condition 47.if ${${UNDEF} == "":?bad-cond:bad-cond} 48. error 49.else 50. error 51.endif 52 53# When the :? is parsed, it is greedy. The else branch spans all the 54# text, up until the closing character '}', even if the text looks like 55# another modifier. 56.if ${1:?then:else:Q} != "then" 57. error 58.endif 59.if ${0:?then:else:Q} != "else:Q" 60. error 61.endif 62 63# This line generates 2 error messages. The first comes from evaluating the 64# malformed conditional "1 == == 2", which is reported as "Bad conditional 65# expression" by ApplyModifier_IfElse. The expression containing that 66# conditional therefore returns a parse error from Var_Parse, and this parse 67# error propagates to CondEvalExpression, where the "Malformed conditional" 68# comes from. 69# expect+1: Bad condition 70.if ${1 == == 2:?yes:no} != "" 71. error 72.else 73. error 74.endif 75 76# If the "Bad condition" appears in a quoted string literal, the 77# error message "Malformed conditional" is not printed, leaving only the "Bad 78# condition". 79# 80# XXX: The left-hand side is enclosed in quotes. This results in Var_Parse 81# being called without VARE_EVAL_DEFINED. When ApplyModifier_IfElse 82# returns AMR_CLEANUP as result, Var_Parse returns varUndefined since the 83# value of the expression is still undefined. CondParser_String is 84# then supposed to do proper error handling, but since varUndefined is local 85# to var.c, it cannot distinguish this return value from an ordinary empty 86# string. The left-hand side of the comparison is therefore just an empty 87# string, which is obviously equal to the empty string on the right-hand side. 88# 89# XXX: The debug log for -dc shows a comparison between 1.0 and 0.0. The 90# condition should be detected as being malformed before any comparison is 91# done since there is no well-formed comparison in the condition at all. 92.MAKEFLAGS: -dc 93# expect+1: Bad condition 94.if "${1 == == 2:?yes:no}" != "" 95. error 96.else 97. error 98.endif 99.MAKEFLAGS: -d0 100 101# As of 2020-12-10, the variable "VAR" is first expanded, and the result of 102# this expansion is then taken as the condition. To force the 103# expression in the condition to be evaluated at exactly the right point, 104# the '$' of the intended '${VAR}' escapes from the parser in form of the 105# expression ${:U\$}. Because of this escaping, the variable "VAR" and thus 106# the condition ends up as "${VAR} == value", just as intended. 107# 108# This hack does not work for variables from .for loops since these are 109# expanded at parse time to their corresponding ${:Uvalue} expressions. 110# Making the '$' of the '${VAR}' expression indirect hides this expression 111# from the parser of the .for loop body. See ForLoop_SubstVarLong. 112.MAKEFLAGS: -dc 113VAR= value 114.if ${ ${:U\$}{VAR} == value:?ok:bad} != "ok" 115. error 116.endif 117.MAKEFLAGS: -d0 118 119# On 2021-04-19, when building external/bsd/tmux with HAVE_LLVM=yes and 120# HAVE_GCC=no, the following conditional generated this error message: 121# 122# make: Bad conditional expression 'string == "literal" && no >= 10' 123# in 'string == "literal" && no >= 10?yes:no' 124# 125# Despite the error message (which was not clearly marked with "error:"), 126# the build continued, for historical reasons, see main_Exit. 127# 128# The tricky detail here is that the condition that looks so obvious in the 129# form written in the makefile becomes tricky when it is actually evaluated. 130# This is because the condition is written in the place of the variable name 131# of the expression, and in an expression, the variable name is always 132# expanded first, before even looking at the modifiers. This happens for the 133# modifier ':?' as well, so when CondEvalExpression gets to see the 134# expression, it already looks like this: 135# 136# string == "literal" && no >= 10 137# 138# When parsing such an expression, the parser used to be strict. It first 139# evaluated the left-hand side of the operator '&&' and then started parsing 140# the right-hand side 'no >= 10'. The word 'no' is obviously a string 141# literal, not enclosed in quotes, which is OK, even on the left-hand side of 142# the comparison operator, but only because this is a condition in the 143# modifier ':?'. In an ordinary directive '.if', this would be a parse error. 144# For strings, only the comparison operators '==' and '!=' are defined, 145# therefore parsing stopped at the '>', producing the 'Bad conditional 146# expression'. 147# 148# Ideally, the conditional expression would not be expanded before parsing 149# it. This would allow to write the conditions exactly as seen below. That 150# change has a high chance of breaking _some_ existing code and would need 151# to be thoroughly tested. 152# 153# Since cond.c 1.262 from 2021-04-20, make reports a more specific error 154# message in situations like these, pointing directly to the specific problem 155# instead of just saying that the whole condition is bad. 156STRING= string 157NUMBER= no # not really a number 158# expect+1: no. 159.info ${${STRING} == "literal" && ${NUMBER} >= 10:?yes:no}. 160# expect+2: Comparison with ">=" requires both operands "no" and "10" to be numeric 161# expect+1: . 162.info ${${STRING} == "literal" || ${NUMBER} >= 10:?yes:no}. 163 164# The following situation occasionally occurs with MKINET6 or similar 165# variables. 166NUMBER= # empty, not really a number either 167# expect+2: Bad condition 168# expect+1: . 169.info ${${STRING} == "literal" && ${NUMBER} >= 10:?yes:no}. 170# expect+2: Bad condition 171# expect+1: . 172.info ${${STRING} == "literal" || ${NUMBER} >= 10:?yes:no}. 173 174# CondParser_LeafToken handles [0-9-+] specially, treating them as a number. 175PLUS= + 176ASTERISK= * 177EMPTY= # empty 178# "true" since "+" is not the empty string. 179# expect+1: <true> 180.info <${${PLUS} :?true:false}> 181# "false" since the variable named "*" is not defined. 182# expect+1: <false> 183.info <${${ASTERISK} :?true:false}> 184# syntax error since the condition is completely blank. 185# expect+2: Bad condition 186# expect+1: <> 187.info <${${EMPTY} :?true:false}> 188 189 190# Since the condition of the '?:' modifier is expanded before being parsed and 191# evaluated, it is common practice to enclose expressions in quotes, to avoid 192# producing syntactically invalid conditions such as ' == value'. This only 193# works if the expanded values neither contain quotes nor backslashes. For 194# strings containing quotes or backslashes, the '?:' modifier should not be 195# used. 196PRIMES= 2 3 5 7 11 197.if ${1 2 3 4 5:L:@n@$n:${ ("${PRIMES:M$n}" != "") :?prime:not_prime}@} != \ 198 "1:not_prime 2:prime 3:prime 4:not_prime 5:prime" 199. error 200.endif 201 202# When parsing the modifier ':?', there are 3 possible cases: 203# 204# 1. The whole expression is only parsed. 205# 2. The expression is parsed and the 'then' branch is evaluated. 206# 3. The expression is parsed and the 'else' branch is evaluated. 207# 208# In all of these cases, the expression must be parsed in the same way, 209# especially when one of the branches contains unbalanced '{}' braces. 210# 211# At 2020-01-01, the expressions from the 'then' and 'else' branches were 212# parsed differently, depending on whether the branch was taken or not. When 213# the branch was taken, the parser recognized that in the modifier ':S,}},,', 214# the '}}' were ordinary characters. When the branch was not taken, the 215# parser only counted balanced '{' and '}', ignoring any escaping or other 216# changes in the interpretation. 217# 218# In var.c 1.285 from 2020-07-20, the parsing of the expressions changed so 219# that in both cases the expression is parsed in the same way, taking the 220# unbalanced braces in the ':S' modifiers into account. This change was not 221# on purpose, the commit message mentioned 'has the same effect', which was a 222# wrong assumption. 223# 224# In var.c 1.323 from 2020-07-26, the unintended fix from var.c 1.285 was 225# reverted, still not knowing about the difference between regular parsing and 226# balanced-mode parsing. 227# 228# In var.c 1.1028 from 2022-08-08, there was another attempt at fixing this 229# inconsistency in parsing, but since that broke parsing of the modifier ':@', 230# it was reverted in var.c 1.1029 from 2022-08-23. 231# 232# In var.c 1.1047 from 2023-02-18, the inconsistency in parsing was finally 233# fixed. The modifier ':@' now parses the body in balanced mode, while 234# everywhere else the modifier parts have their subexpressions parsed in the 235# same way, no matter whether they are evaluated or not. 236# 237# The modifiers ':@' and ':?' are similar in that they conceptually contain 238# text to be evaluated later or conditionally, still they parse that text 239# differently. The crucial difference is that the body of the modifier ':@' 240# is always parsed using balanced mode. The modifier ':?', on the other hand, 241# must parse both of its branches in the same way, no matter whether they are 242# evaluated or not. Since balanced mode and standard mode are incompatible, 243# it's impossible to use balanced mode in the modifier ':?'. 244.MAKEFLAGS: -dc 245.if 0 && ${1:?${:Uthen0:S,}},,}:${:Uelse0:S,}},,}} != "not evaluated" 246# At 2020-01-07, the expression evaluated to 'then0,,}}', even though it was 247# irrelevant as the '0' had already been evaluated to 'false'. 248. error 249.endif 250.if 1 && ${0:?${:Uthen1:S,}},,}:${:Uelse1:S,}},,}} != "else1" 251. error 252.endif 253.if 2 && ${1:?${:Uthen2:S,}},,}:${:Uelse2:S,}},,}} != "then2" 254# At 2020-01-07, the whole expression evaluated to 'then2,,}}' instead of the 255# expected 'then2'. The 'then' branch of the ':?' modifier was parsed 256# normally, parsing and evaluating the ':S' modifier, thereby treating the 257# '}}' as ordinary characters and resulting in 'then2'. The 'else' branch was 258# parsed in balanced mode, ignoring that the inner '}}' were ordinary 259# characters. The '}}' were thus interpreted as the end of the 'else' branch 260# and the whole expression. This left the trailing ',,}}', which together 261# with the 'then2' formed the result 'then2,,}}'. 262. error 263.endif 264 265 266# Since the condition is taken from the variable name of the expression, not 267# from its value, it is evaluated early. It is possible though to construct 268# conditions that are evaluated lazily, at exactly the right point. There is 269# no way to escape a '$' directly in the variable name, but there are 270# alternative ways to bring a '$' into the condition. 271# 272# In an indirect condition using the ':U' modifier, each '$', ':' and 273# '}' must be escaped as '\$', '\:' and '\}', respectively, but '{' must 274# not be escaped. 275# 276# In an indirect condition using a separate variable, each '$' must be 277# escaped as '$$'. 278# 279# These two forms allow the variables to contain arbitrary characters, as the 280# condition parser does not see them. 281DELAYED= two 282# expect+1: no 283.info ${ ${:U \${DELAYED\} == "one"}:?yes:no} 284# expect+1: yes 285.info ${ ${:U \${DELAYED\} == "two"}:?yes:no} 286INDIRECT_COND1= $${DELAYED} == "one" 287# expect+1: no 288.info ${ ${INDIRECT_COND1}:?yes:no} 289INDIRECT_COND2= $${DELAYED} == "two" 290# expect+1: yes 291.info ${ ${INDIRECT_COND2}:?yes:no} 292 293 294.MAKEFLAGS: -d0 295 296 297# In the modifier parts for the 'then' and 'else' branches, subexpressions are 298# parsed by inspecting the actual modifiers. In 2008, 2015, 2020, 2022 and 299# 2023, the exact parsing algorithm switched a few times, counting balanced 300# braces instead of proper subexpressions, which meant that unbalanced braces 301# were parsed differently, depending on whether the branch was active or not. 302BRACES= }}} 303NO= ${0:?${BRACES:S,}}},yes,}:${BRACES:S,}}},no,}} 304YES= ${1:?${BRACES:S,}}},yes,}:${BRACES:S,}}},no,}} 305BOTH= <${YES}> <${NO}> 306.if ${BOTH} != "<yes> <no>" 307. error 308.endif 309 310 311# expect+2: Unknown modifier ":X-then" 312# expect+1: Unknown modifier ":X-else" 313.if ${1:?${:X-then}:${:X-else}} 314.endif 315 316 317# expect+4: Bad condition 318# expect+3: Unknown modifier ":Z1" 319# expect+2: Unknown modifier ":Z2" 320# expect+1: <> 321.info <${ < 0 :?${:Z1}:${:Z2}}> 322