xref: /freebsd/contrib/bmake/unit-tests/cond-short.mk (revision 3e8eb5c7f4909209c042403ddee340b2ee7003a5)
1# $NetBSD: cond-short.mk,v 1.19 2021/12/27 18:54:19 rillig Exp $
2#
3# Demonstrates that in conditions, the right-hand side of an && or ||
4# is only evaluated if it can actually influence the result.
5# This is called 'short-circuit evaluation' and is the usual evaluation
6# mode in most programming languages.  A notable exception is Ada, which
7# distinguishes between the operators 'And', 'And Then', 'Or', 'Or Else'.
8#
9# Before 2020-06-28, the right-hand side of an && or || operator was always
10# evaluated, which was wrong.  In cond.c 1.69 and var.c 1.197 on 2015-10-11,
11# Var_Parse got a new parameter named 'wantit'.  Since then it would have been
12# possible to skip evaluation of irrelevant variable expressions and only
13# parse them.  They were still evaluated though, the only difference to
14# relevant variable expressions was that in the irrelevant variable
15# expressions, undefined variables were allowed.  This allowed for conditions
16# like 'defined(VAR) && ${VAR:S,from,to,} != ""', which no longer produced an
17# error message 'Malformed conditional', but the irrelevant expression was
18# still evaluated.
19#
20# Since the initial commit on 1993-03-21, the manual page has been saying that
21# make 'will only evaluate a conditional as far as is necessary to determine',
22# but that was wrong.  The code in cond.c 1.1 from 1993-03-21 looks good since
23# it calls Var_Parse(condExpr, VAR_CMD, doEval,&varSpecLen,&doFree), but the
24# definition of Var_Parse did not call the third parameter 'doEval', as would
25# be expected, but instead 'err', accompanied by the comment 'TRUE if
26# undefined variables are an error'.  This subtle difference between 'do not
27# evaluate at all' and 'allow undefined variables' led to the unexpected
28# evaluation.
29#
30# See also:
31#	var-eval-short.mk, for short-circuited variable modifiers
32
33# The && operator:
34
35.if 0 && ${echo "unexpected and" 1>&2 :L:sh}
36.endif
37
38.if 1 && ${echo "expected and" 1>&2 :L:sh}
39.endif
40
41.if 0 && exists(nonexistent${echo "unexpected and exists" 1>&2 :L:sh})
42.endif
43
44.if 1 && exists(nonexistent${echo "expected and exists" 1>&2 :L:sh})
45.endif
46
47.if 0 && empty(${echo "unexpected and empty" 1>&2 :L:sh})
48.endif
49
50.if 1 && empty(${echo "expected and empty" 1>&2 :L:sh})
51.endif
52
53# "VAR U11" is not evaluated; it was evaluated before 2020-07-02.
54# The whole !empty condition is only parsed and then discarded.
55VAR=	${VAR${:U11${echo "unexpected VAR U11" 1>&2 :L:sh}}}
56VAR13=	${VAR${:U12${echo "unexpected VAR13" 1>&2 :L:sh}}}
57.if 0 && !empty(VAR${:U13${echo "unexpected U13 condition" 1>&2 :L:sh}})
58.endif
59
60VAR=	${VAR${:U21${echo "unexpected VAR U21" 1>&2 :L:sh}}}
61VAR23=	${VAR${:U22${echo   "expected VAR23" 1>&2 :L:sh}}}
62.if 1 && !empty(VAR${:U23${echo   "expected U23 condition" 1>&2 :L:sh}})
63.endif
64VAR=	# empty again, for the following tests
65
66# The :M modifier is only parsed, not evaluated.
67# Before 2020-07-02, it was wrongly evaluated.
68.if 0 && !empty(VAR:M${:U${echo "unexpected M pattern" 1>&2 :L:sh}})
69.endif
70
71.if 1 && !empty(VAR:M${:U${echo   "expected M pattern" 1>&2 :L:sh}})
72.endif
73
74.if 0 && !empty(VAR:S,from,${:U${echo "unexpected S modifier" 1>&2 :L:sh}},)
75.endif
76
77.if 0 && !empty(VAR:C,from,${:U${echo "unexpected C modifier" 1>&2 :L:sh}},)
78.endif
79
80.if 0 && !empty("" == "" :? ${:U${echo "unexpected ? modifier" 1>&2 :L:sh}} :)
81.endif
82
83.if 0 && !empty(VAR:old=${:U${echo "unexpected = modifier" 1>&2 :L:sh}})
84.endif
85
86.if 0 && !empty(1 2 3:L:@var@${:U${echo "unexpected @ modifier" 1>&2 :L:sh}}@)
87.endif
88
89.if 0 && !empty(:U${:!echo "unexpected exclam modifier" 1>&2 !})
90.endif
91
92# Irrelevant assignment modifiers are skipped as well.
93.if 0 && ${1 2 3:L:@i@${FIRST::?=$i}@}
94.endif
95.if 0 && ${1 2 3:L:@i@${LAST::=$i}@}
96.endif
97.if 0 && ${1 2 3:L:@i@${APPENDED::+=$i}@}
98.endif
99.if 0 && ${echo.1 echo.2 echo.3:L:@i@${RAN::!=${i:C,.*,&; & 1>\&2,:S,., ,g}}@}
100.endif
101.if defined(FIRST) || defined(LAST) || defined(APPENDED) || defined(RAN)
102.  warning first=${FIRST} last=${LAST} appended=${APPENDED} ran=${RAN}
103.endif
104
105# The || operator:
106
107.if 1 || ${echo "unexpected or" 1>&2 :L:sh}
108.endif
109
110.if 0 || ${echo "expected or" 1>&2 :L:sh}
111.endif
112
113.if 1 || exists(nonexistent${echo "unexpected or exists" 1>&2 :L:sh})
114.endif
115
116.if 0 || exists(nonexistent${echo "expected or exists" 1>&2 :L:sh})
117.endif
118
119.if 1 || empty(${echo "unexpected or empty" 1>&2 :L:sh})
120.endif
121
122.if 0 || empty(${echo "expected or empty" 1>&2 :L:sh})
123.endif
124
125# Unreachable nested conditions are skipped completely as well.  These skipped
126# lines may even contain syntax errors.  This allows to skip syntactically
127# incompatible new features in older versions of make.
128
129.if 0
130.  if ${echo "unexpected nested and" 1>&2 :L:sh}
131.  endif
132.endif
133
134.if 1
135.elif ${echo "unexpected nested or" 1>&2 :L:sh}
136.endif
137
138# make sure these do not cause complaint
139#.MAKEFLAGS: -dc
140
141# TODO: Rewrite this whole section and check all the conditions and variables.
142# Several of the assumptions are probably wrong here.
143# TODO: replace 'x=' with '.info' or '.error'.
144V42=	42
145iV1=	${V42}
146iV2=	${V66}
147
148.if defined(V42) && ${V42} > 0
149x=	Ok
150.else
151x=	Fail
152.endif
153x!=	echo 'defined(V42) && $${V42} > 0: $x' >&2; echo
154
155# With cond.c 1.76 from 2020-07-03, the following condition triggered a
156# warning: "String comparison operator should be either == or !=".
157# This was because the variable expression ${iV2} was defined, but the
158# contained variable V66 was undefined.  The left-hand side of the comparison
159# therefore evaluated to the string "${V66}", which is obviously not a number.
160#
161# This was fixed in cond.c 1.79 from 2020-07-09 by not evaluating irrelevant
162# comparisons.  Instead, they are only parsed and then discarded.
163#
164# At that time, there was not enough debug logging to see the details in the
165# -dA log.  To actually see it, add debug logging at the beginning and end of
166# Var_Parse.
167.if defined(V66) && ( ${iV2} < ${V42} )
168x=	Fail
169.else
170x=	Ok
171.endif
172# XXX: This condition doesn't match the one above. The quotes are missing
173# above.  This is a crucial detail since without quotes, the variable
174# expression ${iV2} evaluates to "${V66}", and with quotes, it evaluates to ""
175# since undefined variables are allowed and expand to an empty string.
176x!=	echo 'defined(V66) && ( "$${iV2}" < $${V42} ): $x' >&2; echo
177
178.if 1 || ${iV1} < ${V42}
179x=	Ok
180.else
181x=	Fail
182.endif
183x!=	echo '1 || $${iV1} < $${V42}: $x' >&2; echo
184
185# With cond.c 1.76 from 2020-07-03, the following condition triggered a
186# warning: "String comparison operator should be either == or !=".
187# This was because the variable expression ${iV2} was defined, but the
188# contained variable V66 was undefined.  The left-hand side of the comparison
189# therefore evaluated to the string "${V66}", which is obviously not a number.
190#
191# This was fixed in cond.c 1.79 from 2020-07-09 by not evaluating irrelevant
192# comparisons.  Instead, they are only parsed and then discarded.
193#
194# At that time, there was not enough debug logging to see the details in the
195# -dA log.  To actually see it, add debug logging at the beginning and end of
196# Var_Parse.
197.if 1 || ${iV2:U2} < ${V42}
198x=	Ok
199.else
200x=	Fail
201.endif
202x!=	echo '1 || $${iV2:U2} < $${V42}: $x' >&2; echo
203
204# the same expressions are fine when the lhs is expanded
205# ${iV1} expands to 42
206.if 0 || ${iV1} <= ${V42}
207x=	Ok
208.else
209x=	Fail
210.endif
211x!=	echo '0 || $${iV1} <= $${V42}: $x' >&2; echo
212
213# ${iV2:U2} expands to 2
214.if 0 || ${iV2:U2} < ${V42}
215x=	Ok
216.else
217x=	Fail
218.endif
219x!=	echo '0 || $${iV2:U2} < $${V42}: $x' >&2; echo
220
221# The right-hand side of the '&&' is irrelevant since the left-hand side
222# already evaluates to false.  Before cond.c 1.79 from 2020-07-09, it was
223# expanded nevertheless, although with a small modification:  undefined
224# variables may be used in these expressions without generating an error.
225.if defined(UNDEF) && ${UNDEF} != "undefined"
226.  error
227.endif
228
229
230# Ensure that irrelevant conditions do not influence the result of the whole
231# condition.  As of cond.c 1.302 from 2021-12-11, an irrelevant function call
232# evaluates to true (see CondParser_FuncCall and CondParser_FuncCallEmpty), an
233# irrelevant comparison evaluates to false (see CondParser_Comparison).
234#
235# An irrelevant true bubbles up to the outermost CondParser_And, where it is
236# ignored.  An irrelevant false bubbles up to the outermost CondParser_Or,
237# where it is ignored.
238#
239# If the condition parser should ever be restructured, the bubbling up of the
240# irrelevant evaluation results might show up accidentally.  Prevent this.
241DEF=	defined
242.undef UNDEF
243
244.if 0 && defined(DEF)
245.  error
246.endif
247
248.if 1 && defined(DEF)
249.else
250.  error
251.endif
252
253.if 0 && defined(UNDEF)
254.  error
255.endif
256
257.if 1 && defined(UNDEF)
258.  error
259.endif
260
261.if 0 || defined(DEF)
262.else
263.  error
264.endif
265
266.if 1 || defined(DEF)
267.else
268.  error
269.endif
270
271.if 0 || defined(UNDEF)
272.  error
273.endif
274
275.if 1 || defined(UNDEF)
276.else
277.  error
278.endif
279
280
281all:
282