1# $NetBSD: varmod-ifelse.mk,v 1.17 2021/06/11 13:01:28 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 this case it becomes: 15# 16# variable expression == "variable expression" 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# ${:Uvariable expression} == "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.if ${${:Uvariable expression} == "literal":?bad:bad} 28. error 29.else 30. error 31.endif 32 33# In a variable assignment, undefined variables are not an error. 34# Because of the early expansion, the whole condition evaluates to 35# ' == ""' though, which cannot be parsed because the left-hand side looks 36# empty. 37COND:= ${${UNDEF} == "":?bad-assign:bad-assign} 38 39# In a condition, undefined variables generate a "Malformed conditional" 40# error. That error message is wrong though. In lint mode, the correct 41# "Undefined variable" error message is generated. 42# The difference to the ':=' variable assignment is the additional 43# "Malformed conditional" error message. 44.if ${${UNDEF} == "":?bad-cond:bad-cond} 45. error 46.else 47. error 48.endif 49 50# When the :? is parsed, it is greedy. The else branch spans all the 51# text, up until the closing character '}', even if the text looks like 52# another modifier. 53.if ${1:?then:else:Q} != "then" 54. error 55.endif 56.if ${0:?then:else:Q} != "else:Q" 57. error 58.endif 59 60# This line generates 2 error messages. The first comes from evaluating the 61# malformed conditional "1 == == 2", which is reported as "Bad conditional 62# expression" by ApplyModifier_IfElse. The variable expression containing that 63# conditional therefore returns a parse error from Var_Parse, and this parse 64# error propagates to CondEvalExpression, where the "Malformed conditional" 65# comes from. 66.if ${1 == == 2:?yes:no} != "" 67. error 68.else 69. error 70.endif 71 72# If the "Bad conditional expression" appears in a quoted string literal, the 73# error message "Malformed conditional" is not printed, leaving only the "Bad 74# conditional expression". 75# 76# XXX: The left-hand side is enclosed in quotes. This results in Var_Parse 77# being called without VARE_UNDEFERR. When ApplyModifier_IfElse 78# returns AMR_CLEANUP as result, Var_Parse returns varUndefined since the 79# value of the variable expression is still undefined. CondParser_String is 80# then supposed to do proper error handling, but since varUndefined is local 81# to var.c, it cannot distinguish this return value from an ordinary empty 82# string. The left-hand side of the comparison is therefore just an empty 83# string, which is obviously equal to the empty string on the right-hand side. 84# 85# XXX: The debug log for -dc shows a comparison between 1.0 and 0.0. The 86# condition should be detected as being malformed before any comparison is 87# done since there is no well-formed comparison in the condition at all. 88.MAKEFLAGS: -dc 89.if "${1 == == 2:?yes:no}" != "" 90. error 91.else 92. warning Oops, the parse error should have been propagated. 93.endif 94.MAKEFLAGS: -d0 95 96# As of 2020-12-10, the variable "name" is first expanded, and the result of 97# this expansion is then taken as the condition. To force the variable 98# expression in the condition to be evaluated at exactly the right point, 99# the '$' of the intended '${VAR}' escapes from the parser in form of the 100# expression ${:U\$}. Because of this escaping, the variable "name" and thus 101# the condition ends up as "${VAR} == value", just as intended. 102# 103# This hack does not work for variables from .for loops since these are 104# expanded at parse time to their corresponding ${:Uvalue} expressions. 105# Making the '$' of the '${VAR}' expression indirect hides this expression 106# from the parser of the .for loop body. See ForLoop_SubstVarLong. 107.MAKEFLAGS: -dc 108VAR= value 109.if ${ ${:U\$}{VAR} == value :?ok:bad} != "ok" 110. error 111.endif 112.MAKEFLAGS: -d0 113 114# On 2021-04-19, when building external/bsd/tmux with HAVE_LLVM=yes and 115# HAVE_GCC=no, the following conditional generated this error message: 116# 117# make: Bad conditional expression 'string == "literal" && no >= 10' 118# in 'string == "literal" && no >= 10?yes:no' 119# 120# Despite the error message (which was not clearly marked with "error:"), 121# the build continued, for historical reasons, see main_Exit. 122# 123# The tricky detail here is that the condition that looks so obvious in the 124# form written in the makefile becomes tricky when it is actually evaluated. 125# This is because the condition is written in the place of the variable name 126# of the expression, and in an expression, the variable name is always 127# expanded first, before even looking at the modifiers. This happens for the 128# modifier ':?' as well, so when CondEvalExpression gets to see the 129# expression, it already looks like this: 130# 131# string == "literal" && no >= 10 132# 133# When parsing such an expression, the parser used to be strict. It first 134# evaluated the left-hand side of the operator '&&' and then started parsing 135# the right-hand side 'no >= 10'. The word 'no' is obviously a string 136# literal, not enclosed in quotes, which is ok, even on the left-hand side of 137# the comparison operator, but only because this is a condition in the 138# modifier ':?'. In an ordinary directive '.if', this would be a parse error. 139# For strings, only the comparison operators '==' and '!=' are defined, 140# therefore parsing stopped at the '>', producing the 'Bad conditional 141# expression'. 142# 143# Ideally, the conditional expression would not be expanded before parsing 144# it. This would allow to write the conditions exactly as seen below. That 145# change has a high chance of breaking _some_ existing code and would need 146# to be thoroughly tested. 147# 148# Since cond.c 1.262 from 2021-04-20, make reports a more specific error 149# message in situations like these, pointing directly to the specific problem 150# instead of just saying that the whole condition is bad. 151STRING= string 152NUMBER= no # not really a number 153.info ${${STRING} == "literal" && ${NUMBER} >= 10:?yes:no}. 154.info ${${STRING} == "literal" || ${NUMBER} >= 10:?yes:no}. 155 156# The following situation occasionally occurs with MKINET6 or similar 157# variables. 158NUMBER= # empty, not really a number either 159.info ${${STRING} == "literal" && ${NUMBER} >= 10:?yes:no}. 160.info ${${STRING} == "literal" || ${NUMBER} >= 10:?yes:no}. 161 162# CondParser_LeafToken handles [0-9-+] specially, treating them as a number. 163PLUS= + 164ASTERISK= * 165EMPTY= # empty 166# "true" since "+" is not the empty string. 167.info ${${PLUS} :?true:false} 168# "false" since the variable named "*" is not defined. 169.info ${${ASTERISK} :?true:false} 170# syntax error since the condition is completely blank. 171.info ${${EMPTY} :?true:false} 172