make: sync VarEvalMode constant names with their debug log names

make: provide more context information for parse/evaluate errors

tests/make: replace 'variable expressions' with 'expressions'

tests/make: replace 'variable expression' with 'expression'

Each expression is based on a variable, there's no need for the
verbosity. The wording in make's diagnostics will be changed in a
follow-up commit.

tests/make: force line-based diagnostics to be listed in the tests

This way, contradictions between the intended output and the actual
output are closer together and have a better chance of being spotted.

make: remove redundant type VarParseResult

No functional change.

make: prevent future out-of-bounds errors when parsing expressions

A modifier in an expression ends not only at the next ':' or at the
closing '}' or ')', but also at the end of the string.

Previously, testing for the end of the string had been done separately,
which was error-prone since 2006-05-11, when indirect modifiers were
introduced. Since then, it was possible that the string terminator '\0'
was accidentally skipped in cases where the loop condition only tested
for the ending character. When parsing indirect modifiers, the ending
character is indeed '\0', but when parsing direct modifiers, it is '}'
or ')'.

A welcome side effect is that in the case of unclosed expressions such
as '${VAR:Modifier', the amount of error messages is reduced from 2 or 3
to only 1. The removed error messages were wrong and thus confusing
anyway.

tests/make: test misleading error messages on unclosed expressions

The error messages say 'Unknown modifier' or 'Bad modifier', which is
not entirely correct. The modifier in itself is valid, it's just that
make doesn't expect the end of the string after the modifier.

tests/make: demonstrate that the 'static' in Var_Parse has an effect

make: replace enum bit-field with struct bit-field for VarEvalFlags

This makes the code easier to read, especially in var.c. It also makes
debugging sessions easier since some debuggers don't show enum
bit-fields symbolically as soon as more than one bit is set.

The code outside var.c is basically unchanged, except that instead of
passing the individual flags, there are 4 predefined evaluation modes.
These suffice for all practical use cases. Only in the implementation
deep inside var.c, the value of the flags keepDollar and keepUndef
differs.

There is no way of passing the struct to EnumFlags_ToString, which means
the ToString function has to be spelled out explicitly. This allows for
fine-tuning the representation in the debug log, to reduce the amount of
uppercae letters.

No functional change.

make(1): error out on unknown variable modifiers at parse time

Before, make printed an "error message" that did not include the word
error and thus was not easily identified as such. This "error message"
also did not influence the exit status in the default mode but only in
-dL mode. The error message also didn't include any line number
information and was thus rude.

make(1): add test for parse errors in variable name in Var_SetWithFlags

make(1): add test for expanding variable expressions

make: provide more context information for parse/evaluate errors

tests/make: replace 'variable expressions' with 'expressions'

tests/make: replace 'variable expression' with 'expression'

Each expression is based on a variable, there's no need for the
verbosity. The wording in make's diagnostics will be changed in a
follow-up commit.

tests/make: force line-based diagnostics to be listed in the tests

This way, contradictions between the intended output and the actual
output are closer together and have a better chance of being spotted.

make: remove redundant type VarParseResult

No functional change.

make: prevent future out-of-bounds errors when parsing expressions

A modifier in an expression ends not only at the next ':' or at the
closing '}' or ')', but also at the end of the string.

Previously, testing for the end of the string had been done separately,
which was error-prone since 2006-05-11, when indirect modifiers were
introduced. Since then, it was possible that the string terminator '\0'
was accidentally skipped in cases where the loop condition only tested
for the ending character. When parsing indirect modifiers, the ending
character is indeed '\0', but when parsing direct modifiers, it is '}'
or ')'.

A welcome side effect is that in the case of unclosed expressions such
as '${VAR:Modifier', the amount of error messages is reduced from 2 or 3
to only 1. The removed error messages were wrong and thus confusing
anyway.

tests/make: test misleading error messages on unclosed expressions

The error messages say 'Unknown modifier' or 'Bad modifier', which is
not entirely correct. The modifier in itself is valid, it's just that
make doesn't expect the end of the string after the modifier.

tests/make: demonstrate that the 'static' in Var_Parse has an effect

make: replace enum bit-field with struct bit-field for VarEvalFlags

This makes the code easier to read, especially in var.c. It also makes
debugging sessions easier since some debuggers don't show enum
bit-fields symbolically as soon as more than one bit is set.

The code outside var.c is basically unchanged, except that instead of
passing the individual flags, there are 4 predefined evaluation modes.
These suffice for all practical use cases. Only in the implementation
deep inside var.c, the value of the flags keepDollar and keepUndef
differs.

There is no way of passing the struct to EnumFlags_ToString, which means
the ToString function has to be spelled out explicitly. This allows for
fine-tuning the representation in the debug log, to reduce the amount of
uppercae letters.

No functional change.

make(1): error out on unknown variable modifiers at parse time

Before, make printed an "error message" that did not include the word
error and thus was not easily identified as such. This "error message"
also did not influence the exit status in the default mode but only in
-dL mode. The error message also didn't include any line number
information and was thus rude.

make(1): add test for parse errors in variable name in Var_SetWithFlags

make(1): add test for expanding variable expressions

tests/make: replace 'variable expressions' with 'expressions'

tests/make: replace 'variable expression' with 'expression'

Each expression is based on a variable, there's no need for the
verbosity. The wording in make's diagnostics will be changed in a
follow-up commit.

tests/make: force line-based diagnostics to be listed in the tests

This way, contradictions between the intended output and the actual
output are closer together and have a better chance of being spotted.

make: remove redundant type VarParseResult

No functional change.

make: prevent future out-of-bounds errors when parsing expressions

A modifier in an expression ends not only at the next ':' or at the
closing '}' or ')', but also at the end of the string.

Previously, testing for the end of the string had been done separately,
which was error-prone since 2006-05-11, when indirect modifiers were
introduced. Since then, it was possible that the string terminator '\0'
was accidentally skipped in cases where the loop condition only tested
for the ending character. When parsing indirect modifiers, the ending
character is indeed '\0', but when parsing direct modifiers, it is '}'
or ')'.

A welcome side effect is that in the case of unclosed expressions such
as '${VAR:Modifier', the amount of error messages is reduced from 2 or 3
to only 1. The removed error messages were wrong and thus confusing
anyway.

tests/make: test misleading error messages on unclosed expressions

The error messages say 'Unknown modifier' or 'Bad modifier', which is
not entirely correct. The modifier in itself is valid, it's just that
make doesn't expect the end of the string after the modifier.

tests/make: demonstrate that the 'static' in Var_Parse has an effect

make: replace enum bit-field with struct bit-field for VarEvalFlags

This makes the code easier to read, especially in var.c. It also makes
debugging sessions easier since some debuggers don't show enum
bit-fields symbolically as soon as more than one bit is set.

The code outside var.c is basically unchanged, except that instead of
passing the individual flags, there are 4 predefined evaluation modes.
These suffice for all practical use cases. Only in the implementation
deep inside var.c, the value of the flags keepDollar and keepUndef
differs.

There is no way of passing the struct to EnumFlags_ToString, which means
the ToString function has to be spelled out explicitly. This allows for
fine-tuning the representation in the debug log, to reduce the amount of
uppercae letters.

No functional change.

make(1): error out on unknown variable modifiers at parse time

Before, make printed an "error message" that did not include the word
error and thus was not easily identified as such. This "error message"
also did not influence the exit status in the default mode but only in
-dL mode. The error message also didn't include any line number
information and was thus rude.

make(1): add test for parse errors in variable name in Var_SetWithFlags

make(1): add test for expanding variable expressions

tests/make: force line-based diagnostics to be listed in the tests

This way, contradictions between the intended output and the actual
output are closer together and have a better chance of being spotted.

make: remove redundant type VarParseResult

No functional change.

make: prevent future out-of-bounds errors when parsing expressions

A modifier in an expression ends not only at the next ':' or at the
closing '}' or ')', but also at the end of the string.

Previously, testing for the end of the string had been done separately,
which was error-prone since 2006-05-11, when indirect modifiers were
introduced. Since then, it was possible that the string terminator '\0'
was accidentally skipped in cases where the loop condition only tested
for the ending character. When parsing indirect modifiers, the ending
character is indeed '\0', but when parsing direct modifiers, it is '}'
or ')'.

A welcome side effect is that in the case of unclosed expressions such
as '${VAR:Modifier', the amount of error messages is reduced from 2 or 3
to only 1. The removed error messages were wrong and thus confusing
anyway.

tests/make: test misleading error messages on unclosed expressions

The error messages say 'Unknown modifier' or 'Bad modifier', which is
not entirely correct. The modifier in itself is valid, it's just that
make doesn't expect the end of the string after the modifier.

tests/make: demonstrate that the 'static' in Var_Parse has an effect

make: replace enum bit-field with struct bit-field for VarEvalFlags

This makes the code easier to read, especially in var.c. It also makes
debugging sessions easier since some debuggers don't show enum
bit-fields symbolically as soon as more than one bit is set.

The code outside var.c is basically unchanged, except that instead of
passing the individual flags, there are 4 predefined evaluation modes.
These suffice for all practical use cases. Only in the implementation
deep inside var.c, the value of the flags keepDollar and keepUndef
differs.

There is no way of passing the struct to EnumFlags_ToString, which means
the ToString function has to be spelled out explicitly. This allows for
fine-tuning the representation in the debug log, to reduce the amount of
uppercae letters.

No functional change.

make(1): error out on unknown variable modifiers at parse time

Before, make printed an "error message" that did not include the word
error and thus was not easily identified as such. This "error message"
also did not influence the exit status in the default mode but only in
-dL mode. The error message also didn't include any line number
information and was thus rude.

make(1): add test for parse errors in variable name in Var_SetWithFlags

make(1): add test for expanding variable expressions

make: remove redundant type VarParseResult

No functional change.

make: prevent future out-of-bounds errors when parsing expressions

A modifier in an expression ends not only at the next ':' or at the
closing '}' or ')', but also at the end of the string.

Previously, testing for the end of the string had been done separately,
which was error-prone since 2006-05-11, when indirect modifiers were
introduced. Since then, it was possible that the string terminator '\0'
was accidentally skipped in cases where the loop condition only tested
for the ending character. When parsing indirect modifiers, the ending
character is indeed '\0', but when parsing direct modifiers, it is '}'
or ')'.

A welcome side effect is that in the case of unclosed expressions such
as '${VAR:Modifier', the amount of error messages is reduced from 2 or 3
to only 1. The removed error messages were wrong and thus confusing
anyway.

tests/make: test misleading error messages on unclosed expressions

The error messages say 'Unknown modifier' or 'Bad modifier', which is
not entirely correct. The modifier in itself is valid, it's just that
make doesn't expect the end of the string after the modifier.

tests/make: demonstrate that the 'static' in Var_Parse has an effect

make: replace enum bit-field with struct bit-field for VarEvalFlags

This makes the code easier to read, especially in var.c. It also makes
debugging sessions easier since some debuggers don't show enum
bit-fields symbolically as soon as more than one bit is set.

The code outside var.c is basically unchanged, except that instead of
passing the individual flags, there are 4 predefined evaluation modes.
These suffice for all practical use cases. Only in the implementation
deep inside var.c, the value of the flags keepDollar and keepUndef
differs.

There is no way of passing the struct to EnumFlags_ToString, which means
the ToString function has to be spelled out explicitly. This allows for
fine-tuning the representation in the debug log, to reduce the amount of
uppercae letters.

No functional change.

make(1): error out on unknown variable modifiers at parse time

Before, make printed an "error message" that did not include the word
error and thus was not easily identified as such. This "error message"
also did not influence the exit status in the default mode but only in
-dL mode. The error message also didn't include any line number
information and was thus rude.

make(1): add test for parse errors in variable name in Var_SetWithFlags

make(1): add test for expanding variable expressions

make: prevent future out-of-bounds errors when parsing expressions

A modifier in an expression ends not only at the next ':' or at the
closing '}' or ')', but also at the end of the string.

Previously, testing for the end of the string had been done separately,
which was error-prone since 2006-05-11, when indirect modifiers were
introduced. Since then, it was possible that the string terminator '\0'
was accidentally skipped in cases where the loop condition only tested
for the ending character. When parsing indirect modifiers, the ending
character is indeed '\0', but when parsing direct modifiers, it is '}'
or ')'.

A welcome side effect is that in the case of unclosed expressions such
as '${VAR:Modifier', the amount of error messages is reduced from 2 or 3
to only 1. The removed error messages were wrong and thus confusing
anyway.

tests/make: test misleading error messages on unclosed expressions

The error messages say 'Unknown modifier' or 'Bad modifier', which is
not entirely correct. The modifier in itself is valid, it's just that
make doesn't expect the end of the string after the modifier.

tests/make: demonstrate that the 'static' in Var_Parse has an effect

make: replace enum bit-field with struct bit-field for VarEvalFlags

This makes the code easier to read, especially in var.c. It also makes
debugging sessions easier since some debuggers don't show enum
bit-fields symbolically as soon as more than one bit is set.

The code outside var.c is basically unchanged, except that instead of
passing the individual flags, there are 4 predefined evaluation modes.
These suffice for all practical use cases. Only in the implementation
deep inside var.c, the value of the flags keepDollar and keepUndef
differs.

There is no way of passing the struct to EnumFlags_ToString, which means
the ToString function has to be spelled out explicitly. This allows for
fine-tuning the representation in the debug log, to reduce the amount of
uppercae letters.

No functional change.

make(1): error out on unknown variable modifiers at parse time

Before, make printed an "error message" that did not include the word
error and thus was not easily identified as such. This "error message"
also did not influence the exit status in the default mode but only in
-dL mode. The error message also didn't include any line number
information and was thus rude.

make(1): add test for parse errors in variable name in Var_SetWithFlags

make(1): add test for expanding variable expressions

tests/make: demonstrate that the 'static' in Var_Parse has an effect

make: replace enum bit-field with struct bit-field for VarEvalFlags

This makes the code easier to read, especially in var.c. It also makes
debugging sessions easier since some debuggers don't show enum
bit-fields symbolically as soon as more than one bit is set.

The code outside var.c is basically unchanged, except that instead of
passing the individual flags, there are 4 predefined evaluation modes.
These suffice for all practical use cases. Only in the implementation
deep inside var.c, the value of the flags keepDollar and keepUndef
differs.

There is no way of passing the struct to EnumFlags_ToString, which means
the ToString function has to be spelled out explicitly. This allows for
fine-tuning the representation in the debug log, to reduce the amount of
uppercae letters.

No functional change.

make(1): error out on unknown variable modifiers at parse time

Before, make printed an "error message" that did not include the word
error and thus was not easily identified as such. This "error message"
also did not influence the exit status in the default mode but only in
-dL mode. The error message also didn't include any line number
information and was thus rude.

make(1): add test for parse errors in variable name in Var_SetWithFlags

make(1): add test for expanding variable expressions

make: replace enum bit-field with struct bit-field for VarEvalFlags

This makes the code easier to read, especially in var.c. It also makes
debugging sessions easier since some debuggers don't show enum
bit-fields symbolically as soon as more than one bit is set.

The code outside var.c is basically unchanged, except that instead of
passing the individual flags, there are 4 predefined evaluation modes.
These suffice for all practical use cases. Only in the implementation
deep inside var.c, the value of the flags keepDollar and keepUndef
differs.

There is no way of passing the struct to EnumFlags_ToString, which means
the ToString function has to be spelled out explicitly. This allows for
fine-tuning the representation in the debug log, to reduce the amount of
uppercae letters.

No functional change.

make(1): error out on unknown variable modifiers at parse time

Before, make printed an "error message" that did not include the word
error and thus was not easily identified as such. This "error message"
also did not influence the exit status in the default mode but only in
-dL mode. The error message also didn't include any line number
information and was thus rude.

make(1): add test for parse errors in variable name in Var_SetWithFlags

make(1): add test for expanding variable expressions

make(1): error out on unknown variable modifiers at parse time

Before, make printed an "error message" that did not include the word
error and thus was not easily identified as such. This "error message"
also did not influence the exit status in the default mode but only in
-dL mode. The error message also didn't include any line number
information and was thus rude.

make(1): add test for parse errors in variable name in Var_SetWithFlags

make(1): add test for expanding variable expressions

make(1): add test for parse errors in variable name in Var_SetWithFlags

make(1): add test for expanding variable expressions

make(1): add test for expanding variable expressions