The test cases are the same as in opt-debug-errors.mk. The output
differs in several details though.
Even though the option '-k' is given (which is the default for any tests
that don't override it in unit-tests/Makefile), there is no message
"(continuing)" anywhere.
The failed target is printed twice. Once before the failed commands,
once after. This redundancy is not necessary and may be removed in a
follow-up commit.
The printed commands are in their unexpanded form, which may or may not
be more helpful than the expanded and space-normalized form of compat
mode. Either way, this is an unnecessary inconsistency between compat
mode and jobs mode.
In jobs mode, the message "make: stopped in $dir" is printed for each
failure, which is helpful since each of the jobs may have started in a
separate directory.
Pointed out by Anders Gustafsson on port-hp300@.
https://mail-index.netbsd.org/port-hp300/2021/04/21/msg000201.html
Should be pulled up to netbsd-8 and netbsd-9.
XXX: kernel should use the dhcpd/bootp server address for nfsroot
if the specified next-server (siaddr) is 0.0.0.0?
Even though the new test is quite large, it didn't find any bugs in the
code. The only thing I'm unsure about is why static functions are
exported as well, since they are supposed to be local to the translation
unit.
Previously, the standard NetBSD build generated several lint warnings in
lhash.h from OpenSSL, without providing any hint as to which file
actually included that header. In cases like these, lint now interprets
the line number information in the preprocessor output from GCC to
reconstruct the exact include path to the file in question.
The program check-expect.lua had to be rewritten almost completely since
it assumed that all diagnostics would come from the main file. In all
existing tests, this was true, but these tests did not cover all cases
that occurred in practice. Now it records the complete location of the
diagnostic instead of just the line number.
The argument to most of the functions from <ctype.h> "shall either be
representable as an 'unsigned char' or shall equal the value of the
macro EOF".
When confronted with the infamous warning 'array subscript has type
char', there are enough programmers who don't know the background of
that warning and thus fix it in a wrong way. Neither GCC nor Clang
explain its warning to target these programmers.
Both GCC and Clang warn about 'array subscript has type char', but they
ignore the other requirements of the <ctype.h> functions, even though
these are in the C standard library.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94182https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95177https://stackoverflow.com/a/60696378
The file varmod-loop.mk has grown too large to be single-purpose, plus
it combined parse-time and run-time tests. This has the downside that
as soon as a parse-time test results in an error, the run-time tests are
not run anymore.
