This test lived together with a few unrelated tests in moderrs.mk, it is
better placed in varmod-subst-regex.mk though.
While here, extend, document and explain the test since its purpose was
not obvious from reading the code alone.
It is not always an error for a subexpression to have not matched,
since the regex library can/does not convey how many matches are
expected, only report an error if opts.strict (-dL)
Reviewed by: christos
In the expression ${:U}, the variable name is empty. Since these
expressions are generated by .for loops, the error messages for them
must not end with a trailing space. Putting the variable name in quotes
helps against that.
Replace "variable specification" with the more modern "variable
expression", reduce the number of parentheses, output more than a single
character for modifiers, make it obvious that in expressions such as
${:Serror}, the "" means a variable name.
Before, integer overflow in the :[1..2] modifier had not been detected,
and the actual behavior varied between ILP64 and LP64I32 machines.
Before, the :ts modifier accepted character literals like \012345 and
\x1F600, which don't fit in a single character and were thus truncated.
Before, the :range modifier issued an "Unknown modifier" error message
for :range=x, which was not quite correct. The error message in this
case is now "Invalid number".
In the previous test output, it was unnecessarily hard to see what
happens because of the many empty strings. Enclosing the capturing
groups in parentheses helps against this.
The previous error message "Unclosed substitution" was wrong for several
reasons.
It is not about "unclosed", but about "unfinished" since in the
:@var@...@ modifier the missing '@' does not really close anything.
The word "substitution" may have originated in a time where :S and
:from=to were the only modifiers, and these were indeed substitutions,
but several other modifiers aren't.
The :S and :C modifiers allow an arbitrary delimiter, therefore it is
helpful to enclose the delimiter in quotes, just in case someone chooses
')' or '{' or even ' ' as delimiter.
The bug had been in the handling of the SysV modifier for many years, but
it had not been triggered since the "parsing position for the next
modifier" had been initialized to a non-NULL pointer.
In var.v r1.350, this pointer had been initialized to NULL instead since
every ApplyModifier function must set it in every case where it returns
anything except "default_case".
There might have been a slight chance of tricking make to output a wrong
error message, but nothing worse.
Only a few return statements are still missing from the code coverage.
In ApplyModifier_Assign, the test for an empty variable name is skipped
for now since it segfaults.
In ApplyModifier_SysV after the second ParseModifierPart, the branch for
the missing delimiter is not reached since this case is already checked
for in the first part of the function. To trigger this branch, a
specially crafted, unrealistic string needs to be created, and that's too
complicated for the moment.
* Rename each sub-makefile to *.mk;
* Add a *.exp file of expected output for each sub-makefile;
* Remove test.exp, which is replaced by all the other *.exp files.
* Use suffix rules to generate *.rawout and *.out files for
each test case.
* Rewrite the test and accept targets to adapt to the new way.
The old (now removed) test.exp file is almost identical to the
concatenation (in the correct order) of all the new *.exp files. There
are expected differences in makefile names embedded in the output, and
the new "exit status" lines. Some old "*** Error code 1 (ignored)"
lines are also removed (replaced by new "exit status 1" lines).
rillig