← Back to branch summary

~vcs-imports/pmake/main

« back to all changes in this revision

Viewing changes to unit-tests/varmod-ifelse.mk

  • Committer: rillig
  • Date: 2021-04-19 23:51:42 UTC
  • Revision ID: rillig-20210419235142-lxhuigv2g1klc2rk
make: do not complain when skipping the condition 'no >= 10'

Seen in external/bsd/tmux when building with Clang.  See
varmod-ifelse.mk for the detailed story.

Show diffs side-by-side

added added

removed removed

Lines of Context:
unit-tests/varmod-ifelse.mk
1
 
# $NetBSD: varmod-ifelse.mk,v 1.15 2021/04/19 23:43:14 rillig Exp $
 
1
# $NetBSD: varmod-ifelse.mk,v 1.16 2021/04/19 23:51:42 rillig Exp $
2
2
#
3
3
# Tests for the ${cond:?then:else} variable modifier, which evaluates either
4
4
# the then-expression or the else-expression, depending on the condition.
140
140
# therefore parsing stopped at the '>', producing the 'Bad conditional
141
141
# expression'.
142
142
#
143
 
# TODO: make should at least describe the part of the condition that is
144
 
#  wrong. In this case it is probably the "no >= 10".  Ideally that should
145
 
#  not matter though since the left-hand side of the '&&' evaluates to false,
146
 
#  thus the right-hand side only needs to be parsed, not evaluated.  Since
147
 
#  this is the modifier ':?', which expands subexpressions before parsing
148
 
#  the condition, the "no >= 10" is probably a parse error since it "can be
149
 
#  seen at compile-time" that the operand types of '>=' don't match.  Only
150
 
#  that the concept of "compile-time" does not really apply here.
 
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.
151
151
STRING=         string
152
152
NUMBER=         no              # not really a number
153
153
.info ${${STRING} == "literal" && ${NUMBER} >= 10:?yes:no}.