| Age | Commit message (Collapse) | Author |
|
|
|
No functional change.
|
|
When a .for loop cannot be interpreted correctly, for example when there
are no iteration variables or the number of words doesn't match the
iteration variables, skip the body of the .for loop instead of
interpreting it once.
|
|
Fixes PR 53146.
|
|
|
|
None of the calls to Var_Subst used the return value, and the return
value was always VPR_OK.
No functional change.
|
|
Move For_Break further up, as the functions in that file are sorted from
small to big. The cast from size_t to unsigned int is required by lint.
In parse.c, move the code into a separate function to keep
ParseDirective small. Its only job is to parse the directive and then
delegate to another function doing the actual work.
In the manual page, remove empty lines.
In the test, ensure that .break stops processing of the .for loop
immediately; anything after the .break is not processed anymore.
Replace ':=' with '=', as there is no need to evaluate '$i' early.
Check the expected value in the .mk file instead of the .exp file, to
keep the reading scope as small as possible.
|
|
When .break is encountered within a .for loop
it causes immediate termination.
Outside of a .for loop .break causes a parse error.
Reviewed by: christos
|
|
No binary change
|
|
Previously, some line numbers were stored as signed int while others
were stored as size_t. Since line numbers are never negative, use an
unsigned type. Since the maximum file size for makefiles is 1 GB (see
loadfile), unsigned int is large enough even on 64-bit platforms.
Using a single data types reduces the number of type conversions. Using
unsigned int improves compatibility with C90 (printf %u instead of %zu),
which is needed by bmake, which is derived from usr.bin/make.
No functional change.
|
|
Adding 1 + len bytes but only incrementing the pointer by len bytes
looked suspicious, so use the same expression in both places.
No functional change.
|
|
Suggested by nia.
https://mail-index.netbsd.org/source-changes-d/2022/01/09/msg013564.html
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 buffer of a .for loop is always either empty or ends with '\n'. A
variable name consists of arbitrary non-whitespace characters.
Therefore a variable name can never reach the end of the buffer.
No functional change.
|
|
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'.
|
|
No functional change.
|
|
Put related decisions on the same indentation level, remove unnecessary
negation, keep the code for the '.for' directive together.
No functional change.
|
|
Sort ForLoop members in natural reading order.
Remove redundant condition in ForLoop_ParseItems; at that point, the
number of variables is non-zero.
Rename Buf_AddEscaped since that function is not part of the Buffer API,
it is specific to .for loops.
No functional change.
|
|
No functional change.
|
|
Since the body of a .for loop is scanned from start to end, there is no
need to remember the length of a variable name.
Using memcmp for comparing the variable name was probably overkill since
the variable names are usually very short, so rather compare them byte
by byte.
No functional change.
|
|
No functional change.
|
|
This is a preparation for cleaning up the code for loading and parsing
files, especially the part for including other files and for .for loops.
No functional change.
|
|
The parameter readMore was never NULL.
No functional change.
|
|
Assisted by indent(1), with manual corrections due to its many remaining
bugs.
No functional change.
|
|
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.
|
|
This matches the naming style of the other ForLoop members.
No functional change.
|
|
This saves one memory allocation and a bit of copying, per .for loop.
No functional change.
|
|
The text ${VAR} is not a variable, it's a variable expression.
No functional change.
|
|
In ForLoop_SubstBody, GCC already merged the common subexpressions p[1]
and p[-1], but that was difficult to see for humans as well.
No functional change.
|
|
Most .for loops have a single iteration variable. For these loops, the
difference between the optimized and the unoptimized versions of the
code is negligible.
Remove the optimization since the comment for explaining it was almost
larger than the code itself.
|
|
When a value of a .for loop contained a literal newline, such as from
the expression ${.newline}, that newline was passed verbatim to the
"expanded current body" of the .for loop. There it was interpreted as a
literal newline, which ended the current line and started a new one.
This resulted in several syntax errors.
In cases like these, print a more precise error message.
|
|
|
|
No functional change.
|
|
The word "context" does not fit perfectly to the variables that are
associate with a GNode, as the context is usually something from the
outside and the variables are more like properties inherent to the
GNode.
The term "global context" fits even less. Since the thing where
variables are looked up is commonly named a scope, use that term
instead.
This commit only renames the global variables VAR_GLOBAL, VAR_INTERNAL
and VAR_CMDLINE, plus a few very closely related comments. These are:
GNode.vars (because of line breaks)
GNode_Free (dito)
varname-make_print_var_on_error.mk
varname-make_print_var_on_error-jobs.mk
The debug message in Var_Stats is left as-is since there is no unit test
for it yet.
The other renamings (variable names "context", "ctxt", as well as
further comments) will be done in a follow-up commit.
|
|
|
|
In all cases except one, the boolean argument to Buf_Destroy was
constant. Removing that argument by splitting the function into two
separate functions makes the intention clearer on the call site. It
also removes the possibility for using the return value of Buf_Done,
which would have made no sense.
The function Buf_Done now pairs with Buf_Init, just as in HashTable and
Lst.
Even though Buf_Done is essentially a no-op, it is kept as a function,
both for symmetry with Buf_Init and for clearing the Buffer members
after use (this will be done only in CLEANUP mode, in a follow-up
commit).
|
|
|
|
|
|
This removes the ambiguity whether For_Free is meant to be a
module-exported function or a local function associate with that struct.
Rename the affected functions as well.
|
|
These markers had been used inconsistently. Furthermore the source code
had not been formatted automatically before 2020 at all, otherwise there
wouldn't have been any trailing whitespace left.
|
|
Most of the make code already followed the style of explicitly writing
(ptr != NULL) instead of the shorter (ptr) in conditions.
The remaining 50 instances have been found by an experimental,
unpublished check in lint(1) that treats bool expressions as
incompatible to any other scalar type, just as in Java, C#, Pascal and
several other languages.
The only unsafe operation on Boolean that is left over is (flags &
FLAG), for an enum implementing a bit set. If Boolean is an ordinary
integer type (the default), some high bits may get lost. But if Boolean
is the same as _Bool (by compiling with -DUSE_C99_BOOLEAN), C99 6.3.1.2
defines that a conversion from any scalar to the type _Bool acts as a
comparison to 0, which cannot lose any bits.
|
|
|
|
A memcmp implementation that would check the start and end pointers
first would have detected this possible out-of-bounds memory read.
|
|
|
|
This function does not need to advance the parsing position, which
removes duplicate code.
|
|
|
|
This leaves ForReadMore with the single responsibility of interfacing
with ReadMoreProc in Parse_SetInput.
|
|
Focusing on the "end" is more important than on the data type "ch".
|