This way, it can access the ApplyModifierState, which will be used in a
follow-up commit to reduce the code duplication around the error
handling for missing delimiters.
These two flags have nothing to do with a variable. They are only used
while evaluating a variable expression.
While here, rename the flags and make their documentation more precise.
The word "path" is commonly used either as an abbreviation for pathname
(a string consisting of several directory or file names) or as an
abbreviation for search path (a list of directory names used for
searching files), but not for a single directory.
These typedefs are only intended to help human readers, they do not
provide any type-safety. They also make the pointers explicit, which
had been hidden before by the typedef for Lst and LstNode. Typing a few
'*' is less work than finding out which of the many types are pointers
and which aren't.
In meta.c, the variable "ln" served two completely different purposes,
which have been split again. Register allocation is the job of the
compiler, not of the human source code reader.
Having a pure bitset was wrong.
Instead, there are several alternatives (parse error, eval error, undef
error), and each of them can either have an error message printed (good)
or not (bad). In addition, there are VPE_OK for successful expression
evaluation and VPE_UNKNOWN (only used during migration to the correct
error handling scheme).
The tests varname-dot-parsedir and varname-dot-parsefile had been broken
before if they were run with the "-f $PWD/$test.mk" option. This way of
running the tests is used by FreeBSD.
The output of these tests previously depended upon whether the test
makefile was specified as relative or as absolute path. In NetBSD, it
is specified as relative path, in FreeBSD as absolute path.
Adjust the expected output to hide this difference; in the .rawout files
it is still visible.
This code is so seldom used that it's not necessary to squeeze out every
little bit of performance. It's more important for the code to be clear
and simple.
This is needed to get past the first few seconds in a src/build.sh run.
The nest obstacle is src/tools/Makefile.gnuhost:30, where the variable
MODULE is undefined even though that file says in line 3 that MODULE is
expected to be set. It has been saying this since 2001, but since make
didn't have the corresponding check enabled, this didn't break the
build.
This removes a level of indirection, and the macro names were quite
similar in appearance as well. The macros may have been used by people
whose editors don't recognize C string and character literals when
navigating to the corresponding brace or parenthesis. These editors had
already been confused before this commit since there are also string
literals with unbalanced parentheses, and there are far fewer
compensating comments such as /*{*/ or /*)*/ in the code. In fact, the
only such comment that is left over was in for.c.
This way, there is now a single consistent way of writing these
character literals, which is without macros or comments, since that is
the simplest form.
In deeply nested include chains and .for loops this may be a useful
feature. It's a little tricky to generate an intuitive stack trace,
though not impossible. This explanation also serves as a detailed
documentation about how the .include and .for directives are
implemented.
The previous documentation was focused on the implementation details,
which are already clear from the code. Add some high-level
documentation to help readers understand how this function fits into the
overall picture.
This variable didn't have an intended lifetype of "whole application",
therefore it is better implemented as a local variable that is passed
around the few functions that really need it. It's the same pattern as
in the ModifyWord functions in var.c, only this time without a typedef.
In the usual case where the character is a letter or another ordinary
character, each of the terminal conditions has to be evaluated,
therefore from the compiler's view the order doesn't matter. For
humans, "a unless b" is easier to grasp and more common than "not b but
a", therefore switch to the common pattern.
A while loop is easier to understand than a do-while loop.
An if statement of the form if-something-then-do-something is easier to
understand than if-complicated-condition-then-continue-doing-something.
The documentation was too low-level in parts, essentially repeating the
code in prose. Instead, add more examples and high-level context
information since that is something that the code cannot do.
This code only applies to lint mode (-dL) for now. After a test phase
and a thorough check for possible side effects, it will be activated in
normal mode, too. Having this code in lint mode is required to run
src/build.sh, which relies a lot on using variables with undefined
nested variables in conditions.
In the default mode, any errors about nested undefined variables are not
printed since in Var_Subst, oldVars is true. Therefore, it is not urgent
to properly handle these nested variables correctly there.
