My previous commit message was wrong in saying that the '%prec' was
necessary. It is not necessary.
Most probably I misspelled the name of the grammar rule as opt_comma
instead of comma_opt, which would lead to the same number of conflicts
in the grammar plus a warning, but no build failure.
The '%prec T_COMMA' is necessary to avoid lots of parse errors in the
lint1 unit tests. Curiously, further down in the grammar, for compound
literals, the '%prec T_COMMA' is not necessary, even though the context
looks very similar.
No functional change.
Previously, the grammar syntactically accepted the following code:
int var = .member = 12345;
The designation '.member =' can only be used with brace-enclosed
initializers.
In d_c99_init.c, the initialization of array_with_designator failed.
The designator '.member' from that initialization was not cleaned up
before starting the next initialization.
These two functions are supposed to model the designator that is used
for initializing structs and arrays. The implementation is still buggy
and does not work at all for C99 designators with multiple names, see
d_init_pop_member.c.
For now, just rename the functions to head in the right direction.
No functional change.
The operator NAME has the name 'name', therefore no special case is
needed.
Having the words 'with type' in the message makes the message easier to
find from the debug log. Given that the operator name is used unquoted,
the log message 'name: int value=111' was nearly impossible to find in
the code.
Replace the '()' with an actual word, to avoid any confusion about
whether the type name might be a function type without prototype.
Reduce the amount of '=' signs, instead use commas to separate the
properties of the node.
No functional change outside debug mode.
The previous name could be too easily confused with the type qualifier
'const'. The operator name is mainly used in the debug log, only
occasionally in the output. Since 'constant' is not a "real" operator,
it probably doesn't occur in messages at all.
The debugging code is needed by the soon-to-be-added proper handling of
array subscript initializers such as '.member[123].member = 12345'.
No functional change.
This way, the code is covered by running 'make lint'. The code from the
grammar is not covered, therefore it still uses int instead of bool in a
few places.
Inline the comparison functions for uint64_t. These functions didn't
add any clarity to the code.
No functional change.
The new name accurately describes the structural element that holds such
properties as the separator character and whether the expression value
is considered a single word. The old name ApplyModifiersState was too
long and was meant as a placeholder anyway, when I introduced it in
var.c 1.236 from 2020-07-03.
This is an edge case that doesn't occur in practice since pretty much
nobody dares to use variable names that contain an actual '$' in their
name. This is not about the fairly common VAR.${param} (as written in
the makefile), but instead about the variable whose name is literally
'VAR.${param}'.
The test demonstrates that after the fix, the variable name is taken
exactly as-is for the simple assignment modifier '::='. There are no
such tests for the modifiers '::+=', '::!=' and '::?=', but that's ok.
The code in ApplyModifier_Assign would look assymetrical and suspicious
enough if one of these modifiers would expand its variable name and the
others wouldn't.
In CLEANUP mode, was originally meant to track memory allocations but is
useful during debugging as well, initialize the list. There is no
distinct constant representing an invalid pointer, otherwise that would
have been an even better choice.
An enum with 32 bits would lead to signed integer overflow anyway, so
that definition is not worth keeping even if it works on typical
2-complement platforms.
The definitions for 2, 4 and 8 enum have been unused for several months
now.
No functional change.
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.
The name 'NONE' described the bit pattern, which was not useful to
understand its meaning. Omitting VARE_WANTRES only parses the
expression, without evaluating any part of it.
No functional change, not even in debug mode since Enum_FlagsToString
always returns "none" for all-bits-unset.
This is just to keep the code consistent among the various variable
modifiers. The performance gain is negligible.
The actual assignment to the variable had already been skipped
previously.
No functional change.
No functional change in practical usage. Theoretically this change can
be observed by looking at the generated random numbers for the ':Ox'
modifier, but the quality or exact sequence of these random numbers is
not guaranteed anyway.
In parse-only mode, variable expressions in the argument to that
modifier are not resolved. This led to the error message about the 'Bad
modifier' in var-eval-short.mk.
This affects the modifiers ':E', ':H', ':P', ':Q', ':R', ':T', ':hash',
':q', ':range', ':tl', ':ts', ':tu', and ':u'. All these modifiers are
side-effect free.
Skipping the evaluation for these modifiers is purely for code
consistency and performance.
No functional change.
No functional change, just a tiny bit of performance improvement,
probably not even measurable. Having the code nevertheless serves as a
copy-and-paste template for implementing other modifiers that might
perform more costly tasks.
The test 'var-eval-short' had produced the output 'unexpected' before,
on stderr. It had been generated by '${:Uword:@${FAIL}@expr@}' by
combining the following obscure "features" of make:
1. the ':@' modifier loops over the words of the variable. This
modifier is not really obscure, it still takes some time to get used
to it.
2. the ':@' modifier allows a '$' sign in the variable name, which is
useless in practice.
3. the ':@' modifier creates a temporary loop variable in the global
namespace. Luckily there are only few collisions with other
variable names since their naming conventions differ.
4. after looping over the words of the expression, the temporary global
loop variable is deleted, and at that point the '$' is expanded,
being interpreted as the start of a variable expression.
5. The ':@' modifier deleted the global variable even when it was
called in parse-only mode (without VARE_WANTRES).
When the modifier ':@' was initially added to make in var.c 1.40 from
2000-04-29, Var_Delete didn't expand the variable name. That feature
was added in var.c 1.174 from 2013-05-18, probably without thinking of
this very edge-casey combination of features.
This commit fixes item 5 from the above list. The other obscurities
remain for now.
This way, parsing and evaluating the modifier is only written once in
the code. The downside is that the variable name is allocated even if
VARE_WANTRES is not set, but since this modifier is so obscure and
seldom used this doesn't matter in practice.
This edge case had been so obscure that even discovering this takes
quite some time and requires reading the source code of make.
The manual page doesn't document whether the variable name is expanded
or not, it doesn't even give an example. When this obscure modifier was
initially added in var.c 1.210 from 2017-01-30, Var_Set always expanded
the variable name once, and there was no way around it. Therefore this
expansion has probably been unintentional.
See var-eval-short.mk:46 for the test demonstrating this change.
Previously, the expression ${:Uword:_=VAR} was evaluated including all
its side effects even though it was in an irrelevant branch of the
condition.
No functional change since the only caller of TryParseIntBase0 already
handles all possible parse errors. Without this check, the code just
looked wrong though.
TryParseIntBase0 wrongly returns successful for a string that does not
start with a number at all. Its only caller, ApplyModifier_Words,
already handles all error cases properly.
No functional change.
This aligns the implementation of these modifiers with the requirements
in the long comment starting with 'The ApplyModifier functions'.
No functional change.
Right now, when a variable expression cannot be parsed, the result of
calling Var_Subst is a string containing garbage, and no error is
reported. In addition, there are some silent errors that are not
reported at all. This combination makes it difficult to change the
error handling without introducing subtle breakage in some edge cases.
An example for garbage output is in varmod-subst-regex.mk, in target
mod-regex-compile-error.
No functional change.
The modifier ':C' now only compiles the regular expression if the result
of the expression is actually needed.
Several other modifiers have the same bug of evaluating the expression
in cases where this is not needed. It just doesn't show up because they
don't have any noticeable side effects, other than wasting CPU time.
This affects irrelevant conditions as well.
The additional parameter last_bl_ptr was only necessary because the last
blank was stored as a pointer into the buffer. By storing the index in
the buffer instead, it doesn't need to be updated all the time.
No functional change.
The '?:' operator computing the factor was too hard to read. When
quickly scanning the code, the 1 in the expression looked too much like
it would be added to the indentation, which would turn the indentation
length into a column number, and that again would smell like an
off-by-one error.
No functional change.
The manual page says that the default maximum length of a comment line
is 78. The test 'comments.0' wrongly assumed that this 78 would refer
to the maximum _column_ allowed, which is off by one.
Fix the wording in the test 'comments.0' and remove the (now satisfied)
expectation comments in the test 'token-comment.0'.
Several other tests just happened to hit that limit, fix these as well.
Formatting indent.h required the following manual corrections
afterwards:
The first tab in the comment in line 1 was replaced with a space but
shouldn't be.
The spacing around the '...' in function prototypes was completely
wrong. It looked like 'const char *,...)__printflike', without any
spaces.
The '*' of the return type 'const char *' was tied to the function name,
even though this declaration was only for a single function. In such a
case, it's more appropriate to line up the function names.
The function-like macros were not indented to -di. This is something
that I would not expect from indent, so it's ok to do that manually.
