| Age | Commit message (Collapse) | Author |
|
No functional change.
|
|
In meta mode, the affected variable patterns do not contain a '$'.
Outside of meta mode, Global_SetExpand was only called a single time, so
inline that call.
No functional change.
|
|
No functional change.
|
|
This change leaves only literal format strings in parse.c. It allows
for more detailed error messages than the current "non-zero status" or
"exited on a signal".
No functional change.
|
|
In a .for loop that contains an unclosed .if directive,
Cond_restore_depth generates an error message. If stack traces are
enabled using the option '-dp', the details of the .for loop are added
to the stack trace, but at that point, the ForLoop had already been
freed. To reproduce:
make-2022.01.09.00.33.57 -r -f unit-tests/directive-for.mk -dp
|
|
The stack traces are enabled with the debug logging option '-dp'.
|
|
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'.
|
|
Now that mainNode is globally visible, there is no need to pass it
through function parameters.
No functional change.
|
|
No functional change.
|
|
No functional change.
|
|
No functional change.
|
|
No functional change.
|
|
The parameter readMore was never NULL.
No functional change.
|
|
These types are only needed in the parsing module.
No functional change.
|
|
No functional change.
|
|
No binary change.
|
|
No functional change.
|
|
No binary change.
|
|
The name eunlink suggested a relation with the similarly named functions
emalloc or esnprintf, but that was misleading. Instead, unlink_file
works like unlink, except that it refuses to remove an empty directory.
No functional change.
|
|
Assisted by indent(1), with manual corrections due to its many remaining
bugs.
No functional change.
|
|
The documentation was wrong before since status was not restricted to
only 0 or 1.
No functional change.
|
|
Suggested by sjg, to catch more bugs like the memory leak in cond.c
1.303 from 2021-12-13.
No binary change.
|
|
|
|
References to ${.SUFFIXES} are handled dynamically in
ParseVarnameLong by calling Suff_NamesStr.
The variable cannot be set normally.
Reviewed by: rillig
|
|
The word 'set' sounded too much like it would replace the current file,
but instead the file is pushed to the stack, and the previous file is
continued later.
No functional change.
|
|
In strict bool mode, lint does not consider 'x & y' as having type bool,
if x and y have integer type, it only allows this for enums.
No functional change.
|
|
The word 'fatals' was an unnecessary abbreviation.
No functional change.
|
|
VarEvalFlags has been replaced with VarEvalMode. There were some
comments and tests that still referred to the old names.
No functional change.
|
|
These will be used for making the string handling more efficient,
avoiding allocations, especially when evaluating variable expressions.
Since the string handling has grown quite a bit in the last months,
extract it into its own header file.
No functional change.
|
|
As was apparent in VarEvalFlags_ToString, a bit-set was not the best
data type since most of the flags were not freely combinable. The two
flags that could be combined were keepDollar and keepUndef, but even
these have distinguished names in the debug log.
The downside of struct bit-fields is that they need extra helper
functions in C90 (see nonints.h). Exchange these for a few helper
functions in var.c, to keep the code outside var.c simple.
No functional change.
|
|
No functional change, except for debug logging.
|
|
No functional change.
|
|
In the past few months I had accidentally used C99 features in the make
code. According to tools/README, tools that are used in the build
system should restrict themselves to C90.
This allows make to build with GCC's options "-pedantic
-Wno-system-headers -Dinline= -Wno-error=cast-qual".
I didn't notice anyone actively complaining though, I just wanted to see
how much work this backporting would be. The identifier __func__ is
still used, as in other tools.
No functional change.
|
|
No functional change.
|
|
This makes them easier distinguishable from variable names since the
latter are usually uppercase.
No functional change outside debug mode.
|
|
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 change provides for a more natural reading order in the code.
Placing the scope first makes it immediately clear in which context the
remaining parameters are interpreted.
No functional change.
|
|
|
|
|
|
No functional change.
|
|
Add back Var_SetWithFlags for the one call that doesn't need to expand
the name.
Now one of the flags is encoded in the function name while the others
are encoded in VarSetFlags. This is inconsistent. Maybe there is a
better way to model the different variants of setting a variable.
|
|
After doing the textual renaming across all files, I added a new
function Var_Set that does not expand the variable name. I then undid
the renaming for all calls where the variable name cannot ever contain a
dollar sign. I omitted the word "Expand" from the textual references in
the unit tests and in the debug logging messages since the focus is
usually on the "Set" part, not on the "Expand".
No functional change.
|
|
The function names now follow the naming scheme from the other functions
that handle variables.
There are several calls that remain syntactically unchanged but that
omit the call to strchr('$') now. Since all these calls use constant
variable names, there is no functional change.
|
|
Most previous calls to Var_Exists use constant variable names. Only the
two calls in parse.c need to expand the variable name.
It may be a good idea to expand the variable name once in VarAssign_Eval
instead of repeating the expansion in each of its special cases.
No functional change.
|
|
All callers with a variable name that is guaranteed to not contain a
dollar sign have been converted to call Global_Append instead of the
previous Global_AppendExpand. After that, Global_AppendExpand was
unused, therefore it was effectively just renamed.
|
|
The plain Var_Append now does not expand the variable name anymore. It
is used in situations where the variable name is known to not contain a
dollar sign.
This is a preparation for adding Global_Append, corresponding to
Global_AppendExpand.
|
|
|
|
There are many places where global variables are set or appended to. To
reduce clutter and code size, encode the VAR_GLOBAL in the function
name.
The word Expand in the function names says that the variable name is
expanded. In most of the cases, this is not necessary, but there are no
corresponding functions Global_Set or Global_Append yet.
Encoding the information whether the name is expanded or not in the
function name will make inconsistencies obvious in future manual code
reviews. Letting the compiler check this by using different types for
unexpanded and expanded variable names is probably not worth the effort.
There are still a few bugs to be fixed, such as in SetVar, which expands
the variable name twice in a row.
|