Lines Matching refs:the
3 # Tests for the ${cond:?then:else} variable modifier, which evaluates either
4 # the then-expression or the else-expression, depending on the condition.
6 # The modifier was added on 1998-04-01.
8 # Until 2015-10-11, the modifier always evaluated both the "then" and the
13 # The variable name of the expression is expanded and then taken as the
14 # condition. In the below example it becomes:
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:
24 # Evaluating the variable name lazily would require additional code in
35 # Because of the early expansion, the whole condition evaluates to
36 # ' == ""' though, which cannot be parsed because the left-hand side looks
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
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
63 # This line generates 2 error messages. The first comes from evaluating the
65 # expression" by ApplyModifier_IfElse. The expression containing that
67 # error propagates to CondEvalExpression, where the "Malformed conditional"
76 # If the "Bad condition" appears in a quoted string literal, the
77 # error message "Malformed conditional" is not printed, leaving only the "Bad
80 # XXX: The left-hand side is enclosed in quotes. This results in Var_Parse
82 # returns AMR_CLEANUP as result, Var_Parse returns varUndefined since the
83 # value of the expression is still undefined. CondParser_String is
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.
89 # XXX: The debug log for -dc shows a comparison between 1.0 and 0.0. The
91 # done since there is no well-formed comparison in the condition at all.
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.
110 # Making the '$' of the '${VAR}' expression indirect hides this expression
111 # from the parser of the .for loop body. See ForLoop_SubstVarLong.
120 # HAVE_GCC=no, the following conditional generated this error message:
125 # Despite the error message (which was not clearly marked with "error:"),
126 # the build continued, for historical reasons, see main_Exit.
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
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
144 # For strings, only the comparison operators '==' and '!=' are defined,
145 # therefore parsing stopped at the '>', producing the 'Bad conditional
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
154 # message in situations like these, pointing directly to the specific problem
155 # instead of just saying that the whole condition is bad.
164 # The following situation occasionally occurs with MKINET6 or similar
178 # "true" since "+" is not the empty string.
181 # "false" since the variable named "*" is not defined.
184 # syntax error since the condition is completely blank.
190 # Since the condition of the '?:' modifier is expanded before being parsed and
193 # works if the expanded values neither contain quotes nor backslashes. For
194 # strings containing quotes or backslashes, the '?:' modifier should not be
202 # When parsing the modifier ':?', there are 3 possible cases:
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.
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.
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
216 # changes in the interpretation.
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
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
229 # inconsistency in parsing, but since that broke parsing of the modifier ':@',
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
237 # The modifiers ':@' and ':?' are similar in that they conceptually contain
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
243 # it's impossible to use balanced mode in the modifier ':?'.
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'.
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,,}}'.
266 # Since the condition is taken from the variable name of the expression, not
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.
272 # In an indirect condition using the ':U' modifier, each '$', ':' and
279 # These two forms allow the variables to contain arbitrary characters, as the
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
301 # were parsed differently, depending on whether the branch was active or not.
Indexes created Sat Oct 11 16:09:52 GMT 2025