The return value of Var_Parse is largely redundant to the returned
string. The idea behind the type VarParseResult was to migrate all call
sites to checking this return value instead of the returned string, but
that hasn't happened. Instead, the additional type only added more
complexity.
There was a single place where that return value was actually used, when
parsing conditions. And even in that case, ignoring the VarParseResult
added back an error message that previously hid bugs, in the test
cond-token-plain.mk.
Even though these error messages are redundant in the other tests, they
don't hurt as they don't happen often.
Previously, multi-line directives like '.info' or '.error' reported the
line number of their last line instead of their first line, which is
more usual. This also affected the debug log from '-dp'.
Having a static variable for state that clearly belongs in the parser
looked suspicious, and indeed it was wrong.
When the distinction between .if conditions and expressions of the form
${condition:?:} was added in cond.c 1.68 from 2015-05-05, a new unit
test was added, but it didn't cover this edge case. At that time, the
state of the condition parser consisted of a few global variables
instead of a separate data type, as would have been appropriate for
parsing nested conditions.
Before, there was a "warning" for comparing strings using '<', which was
wrong. That warning was then followed by an error, after parsing the
whole conditional. This was only because it was easier to implement.
Replace the warning with an actual error. This only affects
conditionals in .if lines, the conditionals in the :? modifier such as
${"A" < "B":?smaller:greater} still print 2 errors.
This produces fewer warnings than before, but these were edge cases that
probably didn't matter in practice. The "Malformaed conditional" is
still generated, the set of accepted conditionals is still the same.
The test names have been derived from the current manual page.
All these tests are dummies right now, and the code from the existing
tests will be moved into the new tests step by step.
This is done to prevent modmisc, escape, varmod-edge and varmisc from
growing without any bounds, and to reduce the side-effects of one test
to the others.
rillig