xref: /freebsd/contrib/bmake/unit-tests/varmod-ifelse.mk (revision cfd6422a5217410fbd66f7a7a8a64d9d85e61229)
1# $NetBSD: varmod-ifelse.mk,v 1.8 2020/12/10 16:47:42 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 being set.  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 SubstVarLong.
107.MAKEFLAGS: -dc
108VAR=	value
109.if ${ ${:U\$}{VAR} == value :?ok:bad} != "ok"
110.  error
111.endif
112.MAKEFLAGS: -d0
113
114all:
115	@:;
116