| Age | Commit message (Collapse) | Author |
|
|
|
|
|
At the point where ParseDependencyOp is called, cp is guaranteed to
point to either ':' or '!'.
No functional change.
|
|
|
|
|
|
|
|
|
|
No functional change.
|
|
|
|
No functional change.
|
|
This prepares a refactoring for handling the function 'empty' in
conditionals like '.if'.
The function 'empty' is fundamentally different from all other functions
since it is parsed differently and passes its result on different path
than the other functions. Splitting up these code paths will untangle
the control flow of parsing a condition like 'empty(VARNAME)'. It will
also remove several ARGSUSED and MAKE_ATTR_UNUSED that make the current
code smell.
|
|
This change only affects the behavior for parse errors. Syntactically
well-formed conditions work exactly as before.
|
|
|
|
|
|
|
|
The ports sun2 and vax default to jemalloc 100, as opposed to the rest
of the ports, which use jemalloc 510. Some developers choose to use
jemalloc 100, so let them run the tests with memory debugging as well.
Suggested by mrg on source-changes-d.
|
|
This prevents any trailing whitespace from going unnoticed. It also
marks leading whitespace more clearly, as in the examples with the time
value " 1".
|
|
The majority of the existing error messages and warnings does not
include a period at the end. Follow this style consistently.
|
|
|
|
In expressions using ':L', the value of the variable is delimited by
'{', which makes it easier to recognize it visually, as opposed to being
delimited by 'U'.
|
|
This allows to comment or explain individual test cases.
Remove duplicates.
|
|
The commit message from the previous commit was misleading. This bug
had not been introduced in 2016.02.27.16.20.06 (which was entirely
unrelated) but rather in 2016.02.18.23.33.25.
The commit 2016.02.27.16.20.06 just happened to be the first one from my
make-archive that triggered the bug. That's because I had only checked
out the last commit from each month, to save some disk space.
|
|
Without memory allocator debugging, the newly added test doesn't show
any obvious failure.
With memory allocator debugging enabled, all make versions since
2016.02.27.16.20.06 crash with a segmentation fault.
|
|
|
|
When I started working on usr.bin/make in 2020, I used NetBSD 8, which
used jemalloc 100.
After updating to NetBSD 8 to 9.99.x, the debugging options for jemalloc
stopped working since MALLOC_OPTIONS had been replaced with MALLOC_CONF
in 2019.
Enable malloc debugging again, to reliably reproduce the use-after-free
for the variable modifier ':@'.
|
|
No functional change.
|
|
This saves one memory allocation and a bit of copying, per .for loop.
No functional change.
|
|
|
|
|
|
When run via ATF, the test makefile is not in the current directory.
|
|
|
|
|
|
|
|
|
|
The previous assumption was wrong that only literal '$$' that occur
directly in the right-hand side of a variable assignment would be
affected. Indirect variable definitions are affected as well when they
are evaluated nestedly, as long as the '$$' appears in the text of the
variable that is actually parsed. Whether the '$$' ends up in the
expanded value of the expression doesn't matter though.
|
|
|
|
|
|
|
|
|
|
This puts the expected result of the expressions closer to the
expressions, making the tests self-contained.
The error messages that used to produce trailing spaces have been fixed
in var.c 1.853 from 2021-02-23. The error message now encloses the
variable name in quotes.
|
|
These escape sequences differ from those in string literals in
conditions. In "assignments" to .MAKEFLAGS, \n is a newline, while in a
line like '.if ${VAR} == "\n"', it is simply the letter 'n'.
|
|
This helps tracking down the actual cause of build failures in build
systems like NetBSD's build.sh that use highly abstracted commands that
are mainly defined in terms of variables.
|
|
The releng build job that runs lint fails. It outputs the usage message
of lint, which doesn't include the failing option. After that, make
outputs:
*** Failed target: lint-cgdconfig
*** Failed commands:
${LINT} ${LINTFLAGS} \
${_LDFLAGS.${:Ucgdconfig}:C/-L[ ]*/-L/Wg:M-L*} \
${LOBJS.${:Ucgdconfig}} ${_LDADD.${:Ucgdconfig}}
Make doesn't output the expanded command, therefore the log doesn't show
the offending option '-pthread' that leads to the usage message.
|
|
|
|
|
|
Just to prevent a half-baked fix to the current behavior that would
concatenate the modifiers of the two expressions, leading to
${LATER:value=sysv:tl} in this case. That expression would be
interpreted as having only a single modifier that would replace the
suffix 'value' with 'sysv:tl'. This is because the SysV modifier
':from=to' spans until the end of the expression.
|
|
Reported by Simon J Gerraty via private mail.
This edge case has been handled in essentially the same way since at
least 2000-05-30, probably several years earlier as well. The test file
is:
---- snip ----
.undef LATER
.undef later
INDIRECT:= ${LATER:S,value,replaced,}
indirect:= ${INDIRECT:C,S,s,}
# expect+1: Unknown modifier "s,value,replaced,"
.if ${indirect} != ""
. error
.else
. warning XXX Neither branch should be taken.
.endif
LATER= uppercase-value
later= lowercase-value
# expect+1: Unknown modifier "s,value,replaced,"
.if ${indirect} != "uppercase-replaced"
. warning XXX Neither branch should be taken.
.else
. error
.endif
all:
@:;
---- snap ----
The output from 'make -r -f later.mk' is:
make-2000.05.30.02.32.21
| make: Unknown modifier 's'
|
| "later.mk", line 9: Need an operator
| make: Unknown modifier 's'
|
| "later.mk", line 15: Need an operator
| Fatal errors encountered -- cannot continue
| exit status 1
make-2000.12.30.16.38.22
The pathnames in the error message gets absolute:
make-2001.01.23.02.48.05
| make: Unknown modifier 's'
|
| ".../later.mk", line 9: Need an operator
| make: Unknown modifier 's'
|
| ".../later.mk", line 15: Need an operator
| Fatal errors encountered -- cannot continue
| exit status 1
make-2001.01.23.02.48.05
All error messages get 'make:' as a common prefix:
make-2001.02.23.21.11.38
| make: Unknown modifier 's'
|
| make: ".../later.mk" line 9: Need an operator
| make: Unknown modifier 's'
|
| make: ".../later.mk" line 15: Need an operator
| make: Fatal errors encountered -- cannot continue
| exit status 1
make-2001.05.29.17.37.52
The 'stopped in' gets added:
make-2001.06.12.23.36.18
| make: Unknown modifier 's'
|
| make: ".../later.mk" line 9: Need an operator
| make: Unknown modifier 's'
|
| make: ".../later.mk" line 15: Need an operator
| make: Fatal errors encountered -- cannot continue
|
| make: stopped in ...
| exit status 1
make-2002.02.21.22.21.34
The empty lines between the error messages get removed.
make-2002.03.21.11.42.21
| make: Unknown modifier 's'
| make: ".../later.mk" line 9: Need an operator
| make: Unknown modifier 's'
| make: ".../later.mk" line 15: Need an operator
| make: Fatal errors encountered -- cannot continue
|
| make: stopped in ...
| exit status 1
make-2009.10.15.02.27.44
The error message for unknown directives gets more helpful:
make-2009.11.19.06.48.37
| make: Unknown modifier 's'
| make: ".../later.mk" line 9: Unknown directive
| make: Unknown modifier 's'
| make: ".../later.mk" line 15: Unknown directive
| make: Fatal errors encountered -- cannot continue
|
| make: stopped in ...
| exit status 1
make-2010.02.22.19.20.33
The directives '.error', '.warning' and '.info' get added:
make-2010.04.29.23.12.21
| make: Unknown modifier 's'
| make: ".../later.mk" line 9: warning: XXX Neither branch should be taken.
| make: Unknown modifier 's'
| make: ".../later.mk" line 15: warning: XXX Neither branch should be taken.
| exit status 0
make-2020.12.20.19.37.23
The error message about an unknown variable modifier gets line number
information:
make-2020.12.20.19.47.34
| make: ".../later.mk" line 6: Unknown modifier 's'
| make: ".../later.mk" line 9: warning: XXX Neither branch should be taken.
| make: ".../later.mk" line 14: Unknown modifier 's'
| make: ".../later.mk" line 15: warning: XXX Neither branch should be taken.
| make: Fatal errors encountered -- cannot continue
| make: stopped in ...
| exit status 1
make-2021.02.23.15.07.58
The error message about an unknown variable modifier gets more context
than only a single letter:
make-2021.02.23.15.19.41
| make: ".../later.mk" line 6: Unknown modifier "s,value,replaced,"
| make: ".../later.mk" line 9: warning: XXX Neither branch should be taken.
| make: ".../later.mk" line 14: Unknown modifier "s,value,replaced,"
| make: ".../later.mk" line 15: warning: XXX Neither branch should be taken.
| make: Fatal errors encountered -- cannot continue
| make: stopped in ...
| exit status 1
|
|
If we replace ${.OBJDIR} with <objdir> some tests produce
different results depending on the value of .OBJDIR
For similar reasons eliminate .OBJDIR and .PATH from output of
varname-empty
Reviewed by: rillig
|
|
Having a static variable for state that clearly belongs in the parser
looked suspicious, and indeed it was wrong.
When the distinction between .if conditions and expressions of the form
${condition:?:} was added in cond.c 1.68 from 2015-05-05, a new unit
test was added, but it didn't cover this edge case. At that time, the
state of the condition parser consisted of a few global variables
instead of a separate data type, as would have been appropriate for
parsing nested conditions.
|
|
|