tests/lint: add basic tests for lint (not lint1 or lint2)

tests/lint: add test skeletons for messages from lint2

branches: 1.1.2;
Deprecate tests/util.

tests/lint: move check-expect.lua to tests/lint1

It is only used for testing lint1, not for lint2 or xlint.

tests/lint: remove .exp files, as they have become redundant

Now that each lint1 test lists all generated diagnostics as 'expect'
comments, the information from the .exp files is no longer needed. The
only information that gets lost is the order of the diagnostics, which
is mostly relevant for paired messages like 'inconsistent definition' +
'previous definition was here'.

tests/lint: treat a missing .exp file like an empty one

Previously, a missing .exp file skipped all the checks, that is, the
tests wouldn't fail if there were some unexpected new message.

tests/lint: make 'expect+-' comments stricter

Previously, the expectations from these comments were already satisfied
if the expectation occurred somewhere in the actual message from lint.
This meant that the prefix 'error:' or 'warning:' could be omitted from
the 'expect' comment. These omissions were hard to see in a manual
review. Now any omissions must be visually marked with '...'.

The test msg_342 now reports its messages properly as being in the file
msg_342.c, rather than msg_341.c. This had been a copy-and-paste
mistake.

tests/lint: rename local variables in check-expect.lua

Enough time has passed since I wrote that little program to make me
forget the naming scheme I had in mind back then. Prefix the variable
names with the source of their data, 'c_' or 'exp_', to provide a bit of
orientation.

No functional change.

tests/lint: do not interpret 'expect:' comments, only 'expect+-n:'

Only the tests in msg_*.c had used the short form of the 'expect:'
comments. The other tests used the more detailed variant 'expect+n:' or
'expect-n:'.

tests/lint: add more details to tests from msg_300 until msg_343

tests/lint: add more details to messages in msg_200 until msg_299

Add some tests that were previously empty. Some other tests are still
empty.

tests/lint: make expectation lines in the tests more detailed

This commit migrates msg_100 until msg_199.

tests/lint: replace 'expect' comments with 'expect+-' comments

The 'expect+-' comments provide more context, which makes it easier to
read the .c files on their own, without having to look up the actual
diagnostics in the .exp files.

Add tests for messages 105 and 106, which were about the obscure feature
of some traditional C compilers that allowed the expression 'x->member'
to access a struct member, even if 'x' had integer type.

The remaining tests will be migrated in a future commit.

tests/lint: make error handling simpler

The previous form was better suited for integrated unit tests (as in
distrib/sets/fmt-list). These small validation programs are easy enough
to be tested from the command line though.

tests/lint: document placement of lint comments

tests/lint: suggest better quickfix for expected lint diagnostics

The /* expect */ comments are usually so detailed that they are placed
in a line of their own, referring to the following line.

tests/lint: test folding of constant expressions

Since November 2001, there is a comment above the function 'fold' that
suggests there are a few bugs concerning overflow detection. Add some
first 'proper regression tests' to prove these bugs.

tests/lint: fix check-expect.lua for empty .exp file

An absent .exp file is equivalent to an empty .exp file. In neither of
these cases must the corresponding .c file declare any expected
diagnostics.

tests/lint: remove unused variables

lint: in code from included files, print stack trace

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.

tests/lint: one comment per expected diagnostic

This makes it possible to check for diagnostics that contain commas.

tests/lint: force 'expect' annotations

tests/lint: allow 'expect' comments to refer to other lines

This allows /* expect+1: ... */ to refer to the following line, as well
as /* expect-1: ... */ to refer to the previous line. This avoids
horizontal scrolling to see the expectations, it also allows these
expectations comments to be more verbose, mentioning the whole
diagnostic in many cases.

The 'expect' comments don't need to be at the end of a line anymore
since that was rather surprising. The one 'expect' comment that had not
been at the end of the line was in d_c99_bool_strict.c and was not
intended to be ignored.

lint: force each test to declare the expected diagnostics

By listing the expected diagnostics directly at the code that triggers
the diagnostics, it is easier to cross-check whether the diagnostics
make sense.

No functional change to lint itself.

lint: ensure that '# line' directives in tests are correct

It's too easy to forget one of them when adding or removing some lines.
This would make it more difficult to locate the lines referenced in the
error messages.

lint: prepare to make strict bool mode even stricter

Currently, strict bool mode still allows integer constant expressions to
be converted implicitly to bool. This is something that other languages
such as Go, Java, C#, Pascal don't allow.

By providing a custom implementation of <stdbool.h> that defines false
and true to custom bool constant identifiers, lint will cover these
cases as well.

To prepare for this, reword the rules and restructure the tests in
d_c99_bool_strict.c.

lint: add new check for strict bool mode

In strict bool mode, bool is considered incompatible with all other
scalar types, just as in Java, C#, Pascal.

The controlling expressions in if statements, while loops, for loops and
the '?:' operator must be of type bool. The logical operators work on
bool instead of int, the bitwise operators accept both integer and bool.
The arithmetic operators don't accept bool.

Since <stdbool.h> implements bool using C preprocessor macros instead of
predefining the identifiers "true" and "false", the integer constants 0
and 1 may be used in all contexts that require a bool expression.
Except from these, no implicit conversion between bool and scalar types
is allowed.

See usr.bin/tests/xlint/lint1/d_c99_bool_strict.c for more details.

The command line option -T has been chosen because all obvious choices
(-b or -B for bool, -s or -S for strict) are already in use. The -T may
stand for "types are checked strictly".

The default behavior of lint doesn't change. The strict bool check is
purely optional.

An example program for strict bool mode is usr.bin/make, which has been
using explicit comparisons such as p != NULL, ch != '\0' or n > 0 in
most places for a long time now, even before the refactoring in 2020.

tests/lint: reorganize tests

Tests for a single working language construct don't usually need a
separate file, they can be grouped together, like in expr.c or gcc.c.

tests/lint: test command line parsing for message and query IDs

The parsing methods differ but shouldn't.

tests/lint: fix source directory for looking up the .exp-ln files

tests/lint1: the redundantly listed files contained .exp-ln as well

tests/lint: fix resolving of wildcards in builds from other directories

tests/lint: remove redundancy from Makefile

The list of test files is already kept in distrib/sets/lists/tests/mi.

tests/lint: remove redundant tests

The names of the tests were misleading: 'recursive' should have been
'nested', and the interesting topic in the 'cast' tests was not the cast
but the pointer dereference.

tests/lint: merge tests for '>>'

tests/lint: merge tests for declaration after statement

lint: add support for the C11 type qualifier '_Atomic'

That keyword can be used as a type specifier as well, support for that
will be added later.

tests/lint: test _Atomic, added in C11

tests/lint: add test for parsing sizeof expressions

tests/lint: merge tests for ':?' with null pointer constant

lint: add additional queries that are not enabled by default

In the last 18 months, several lint warnings have been made adjusted to
allow common usage patterns. For example, lint no longer warns about a
constant condition in the statement 'do { ... } while (false)' (message
161), as this pattern is well-known in statement-like macros, making it
unlikely that the 'false' is a mistake. Another example is casts
between unequal pointer types (message 247) for a few well-known
patterns that are unlikely to be bugs.

Occasionally, it is useful to query the code for patterns or events that
would not justify a warning. These patterns are modeled as predefined
queries that can be selected individually, in addition to and
independently of the existing warnings and errors.

New queries can be added as needed, in the same way as new warnings.
Queries that are deemed no longer used can be deactivated in the same
way as warnings that are no longer used.

As long as none of the queries is enabled, they produce a minimal
overhead of querying a single global variable. Computations that are
more expensive than a few machine instructions should be guarded by
any_query_enabled.

https://mail-index.netbsd.org/source-changes-d/2022/06/28/msg013716.html

ok christos@

tests/lint: move check-expect.lua to tests/lint1

It is only used for testing lint1, not for lint2 or xlint.

tests/lint: remove .exp files, as they have become redundant

Now that each lint1 test lists all generated diagnostics as 'expect'
comments, the information from the .exp files is no longer needed. The
only information that gets lost is the order of the diagnostics, which
is mostly relevant for paired messages like 'inconsistent definition' +
'previous definition was here'.

tests/lint: add more details to messages in msg_200 until msg_299

Add some tests that were previously empty. Some other tests are still
empty.

tests/lint: make expectation lines in the tests more detailed

This commit migrates msg_100 until msg_199.

tests/lint: fix test for loss of accuracy on ILP32 platforms

The test had been wrong since msg_132.c 1.14 from 2022-05-30.

Using 'unsigned long' in a test that was intended to behave the same on
ILP32 and LP64 was an accident. Use 'unsigned long long' instead, which
is 64-bits wide on all platforms supported by lint.

Move the test about conversion from 'long' to 'int' to the
platform-specific test files.

Noticed by martin@ on powerpc.

tests/lint: add more tests for __alignof__

tests/lint: adjust tests to reflect missing support of __alignof__

The change in lex.c 1.129 attempted to add support for __alignof, in
addition to the existing support for __alignof__. It failed by removing
support for __alignof__, while allowing the plain 'alignof' instead.

lint: revert resolving grammar conflicts for labeled statements

Restore the grammar rule for labeled_statement as it was before cgram.y
1.400 from 2022-04-24. This allows labels with attributes again. Fix
the wrong interpretation in the tests; the attributes belong to the
label, not to the statement.

Today in the morning, when I thought that the change in cgram.y 1.400
were innocent, I accidentally ran lint only with the options '-Sw' but
forgot the option '-g' for GNU mode. Without that option, the token
'__attribute__' is unknown, which unsurprisingly leads to lots of syntax
errors, and these didn't change with that commit. The actual change was
only visible in GNU mode.

lint: fix instructions for adding a new test

lint: remove unused message 70, add some more tests

tests/lint: add tests for a few early messages

tests/lint: test excess braces around initializers

tests/lint: remove generated shell program on 'make clean'

tests/lint: demonstrate wrong warning for __builtin_alloca

lint: warn if an enum name is used for mismatched array access

This helps to keep the enum definition and the straight-forward
implementation of a to_string or name function in sync.

The test for message 241 had to be adjusted because of exactly this bug.
That test defined a bit mask enum but accessed it like a value enum
type.

tests/lint: add tests for platform characteristics

Running lint in usr.bin/make on i386 fails due to this warning:

cond.c(800): warning: argument #3 is converted from 'unsigned char' to
'unsigned int' due to prototype [259]

This warning only occurred on i386 but not on sparc or x86_64. Try to
reproduce the test situation in platform_int.

The platform code in t_integration.sh was not strict enough, it didn't
check for multiple conditions, such as in msg_132_ilp32. That test was
only supposed to run on ILP32 platforms where size_t is unsigned int. It
also ran on sparc, even though size_t is long there.

tests/lint: add more tests for direct-abstract-declarator

Lint's grammar in this area differs a lot from the grammar in C99. GCC's
parser has a long comment about special cases in this area. It's tricky
to even parse these type names correctly, let alone assign them the
correct types, that's why it needs more tests before trying to refactor
that code.

lint: add more details to error about redeclaration

Message 27 is triggered by several conditions. The one triggered by
register_vget in sbin/fsck_lfs/vnode.c needs more details than the
others.

tests/lint: test line number tracking with \v and \f

tests/lint: test GCC builtins for overflow in strict bool mode

Seen in inetd.c.

tests/lint: add test for prototype conversions in C90

The purpose of warning 259 is to find function calls that differ in the
ABI. The warning's original purpose was not to warn about lossy
conversions, that's just a side effect.

Warning 259 had been implemented before C99 was published, which is more
than 20 years ago. In the meantime, almost all code has migrated to
using function prototypes. With the default lint flags from NetBSD's
<sys.mk>, it would rather make sense to focus on lossy conversions now.

To prepare for potentially upcoming differences in lint's C90 and C99
modes, clone the test now as far as possible. The test for C90 mode is
smaller than for C99 mode, since 'long long' was not available back
then.

tests/lint: test conversion from long long to intptr_t on ilp32

Seen in usr.bin/make/var.c:1608.

tests/lint: demonstrate wrong constant folding in strict bool mode

Found while investigating wrong constant folding in default mode.

tests/lint: test folding of constant expressions

Since November 2001, there is a comment above the function 'fold' that
suggests there are a few bugs concerning overflow detection. Add some
first 'proper regression tests' to prove these bugs.

tests/lint: test arithmetic promotions and enums

lint: warn about 'char * = strchr(const char *, int)'

Found in findcc.c, there are about 25 other instances of this
incongruency in the whole source tree.

For more examples of functions from the C Standard Library that
implicitly remove the 'const' qualifier from an argument, see the C++
include file 'cstring'.

tests/lint: test emitting 128-bit integer types for lint2

tests/lint: test GCC extension for casting to union type

tests/lint: test casting a struct to another struct

tests/lint: test the usual arithmetic conversions in traditional C

tests/lint: test the usual arithmetic conversions

The function 'balance' does not mention __uint128_t and nevertheless
works as expected. Need to investigate further.

tests/lint: cover every code line in the grammar

tests/lint: test declarators with attributes

tests/lint: demonstrate missing support for GCC typeof

tests/lint: test parse errors in statements

These errors are really unrealistic. Most parse errors that occur in
statements are already handled elsewhere and continue with the next
semicolon.

The tests had to be split into two separate files because lint assumes
that after the 5th parse error, it does not make sense to continue this
translation unit.

tests/lint: test parsing of type_name

tests/lint: cover more edge cases in the parser

tests/lint: test struct declarations

tests/lint: test precedence of operators

tests/lint: add several tests for edge cases in the grammar

tests/lint: test binary integer literals and underscores

tests/lint: take archsubdir from usr.bin/xlint/Makefile.inc

This fixes the tests on the various ARM platforms where the platform
name does not correspond to MACHINE_ARCH, such as earmv7hf.

lint: support __attribute__((hot))

The corresponding attribute 'cold' was already added in cgram.y 1.84
from 2016-12-29.

tests/lint: test dangling else

tests/lint: test declarations

tests/lint: add more tests for covering the grammar

tests/lint: add test for unrealistic edge cases in declarations

The example code for triggering these grammar rules looks completely
contrived. Even if lint had not implemented these cases, hopefully
nobody would have ever noticed.

tests/lint: add tests for C90 mode and malformed declarations

In the grammar, 148 lines are still uncovered by the tests. The
untested parts are mostly obscure declarations and a few parse errors.

tests/lint: add tests for GCC __attribute__

Before fixing the wrong handling of __attribute__ that is demonstrated
at the end of gcc_attribute.c, ensure that the attribute handling works
in the most basic cases.

Lint currently accepts __attribute__ in more places than it should.
This leads to some ambiguities in the grammar.

test/lint: demonstrate wrong warnings for 128-bit shifts

lint: remove remaining support for lvalue casts

These had been GCC extensions until GCC 3.4, they were removed in GCC
4.0.

tests/lint: re-enable test c99_bool_strict_suppressed

It had been disabled accidentally in the previous commit.

lint: remove outdated assertion

Since err.c 1.12 from 2000-07-06, lint allows to suppress individual
error messages. Suppressed error messages do not increment nerr.
Keeping nerr at 0 had triggered the assertion.

tests/lint: add test for suppressing errors in strict bool mode

tests/lint: fix test for character comparison on macppc

On macppc, char == unsigned char, which generates one more warning than
on platforms where char == signed char.

tests/lint: add test for array subscripts in C99 initialization

lint: fix wrong warning about out-of-range value '\xff' for char

This only affects platforms where char has the same representation as
unsigned char.

tests/lint: add test that only runs where char == unsigned char

There a 4 regular NetBSD builds where lint is activated. All these
builds run on platforms where char == signed char.

The official test runs from https://releng.netbsd.org/test-results.html
mostly have char == signed char as well.

However, lint behaves differently on platforms with char == unsigned
char. On these platforms, a simple "char ch = '\xff'" leads to the
bogus warning that "conversion of 'int' to 'char' is out of range".

tests/lint: add 'make accept' to update the expected output

tests/lint: add tests for ILP32 platforms

Previously, all tests for lint had to produce the exact same output, no
matter which platform they ran on. This differs from practical needs
since lint is intended to produce different results depending on whether
the platform is ILP32 or LP64.

Examples for these are type conversions and the widths of the integer
types during lexical analysis.

lint: require C11 for _Generic

This does not have any effect in practice since the option -g
(originally meant for GCC extensions to the C standards) implicitly
allows all features from C11, since err.c 1.111 from 2021-04-14.

Since the default lint flags for NetBSD builds include the option -g,
this allows all C11 features.

Currently it is not possible to say "allow GNU extensions but not C11".

lint: fix option -Ac11, add test for _Generic

Previously, selecting the option -Ac11 allowed features from C11 but at
the same time prohibited 'long long', which was added in C99. This was
caused by the option -s, which is interpreted as "allow features from
C90, but no later".

The test for _Generic, which has been added in C11, demonstrates that
the current implementation is broken. Lint currently thinks that the
return type of a _Generic selection is the type of the expression, but
it really is the type of the selected expression. In the current tests,
this is always 'const char *', but C11 does not require that the types
of a generic selection are compatible.

tests/lint: rename expected .ln file to .exp-ln

This way, the hack for suffixes is no longer needed.

tests/lint: test syntax error in initialization using designator

This test prepares the upcoming refactoring of the grammar.

lint: fix endless loop on unfinished comment at EOF

Found using afl.

lint: fix assertion after malformed for loop

Found using afl.

lint: fix assertion failure in struct with unnamed member

Found using afl.

lint: fix crash in malformed initialization

tests/lint: add test cases for lexical analysis

tests/lint: make test d_gcc_extension platform-independent

That test was intended to test the keywords '__extension__' and
'__typeof'. The GCC builtin functions were just a side-effect.

These built-in functions generated error messages on platforms such as
amd64 where sizeof(long double) != sizeof(double), but not on others
such as sparc.

The current infrastructure for the lint tests cannot handle tests with
platform-dependent outcome.

lint: add more specific warning for bit-field of type plain 'int'

Previously, declaring a bit-field of type plain 'int' resulted in this
warning:

warning: nonportable bit-field type 'int' [34]

This warning was too unspecific to be actionable, and until yesterday it
didn't even include the type. In order to allow this warning to be
understood and properly fixed, describe the actual nonportability more
precisely:

warning: bit-field of type plain 'int' has
implementation-defined signedness [344]

lint: warn about unreachable case labels for '&&'

See octeon_gmxreg.h 1.2 from 2020-06-18 for an example, where
RXN_RX_INBND_SPEED was cleaned up without adjusting the corresponding
code in octeon_gmx.c.

tests/lint: test bitwise mismatch in switch statement

branches: 1.55.2;
tests/lint: add test for bit-field types in GCC mode

tests/lint: demonstrate missing support for __packed __aligned

tests/lint: add very basic tests for GCC __attribute__

tests/lint: add test for typeof after statement

Found by christos@.

Put things back, emit.ln it was meant to be there.

remove emit.ln; looks like an accident and breaks the build.

tests/lint: fix the hack for emit.ln to also work if MKUPDATE != "no"

tests/lint: fix inconsistent operator for emit.ln

The build failed with:

nbmake[8]: "/.../src/share/mk/bsd.files.mk" line 47:
Inconsistent operator for /.../emit.ln

tests/lint1: fix build error "must name an existing directory"

The build failed with this error message:

x86_64--netbsd-install: the last argument (/.../emit.ln) must
name an existing directory

The cause for this message was that ${DESTDIR}/.../emit.ln has
${DESTDIR}/.../emit.c as implicit target, which is kind of correct but
unintended in this case. Because of this, the command 'install' was run
like this:

install ${NETBSDSRCDIR}/.../emit.ln ${DESTDIR}/.../emit.c \
${DESTDIR}/.../emit.ln

tests/lint: record all files from FILES in distrib/sets/lists/tests/mi

tests/lint: add emit.ln to the release files

lint: test emitting of symbol information in the .ln files

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.

tests/lint: demonstrate assertion failure in initialization

lint: add test for newly added message about static array size

tests/lint: demonstrate wrong lint warning about complex variables

lint: in code from included files, print stack trace

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.

lint: warn about for wrong type cast in argument to ctype.h functions

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=94182
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95177
https://stackoverflow.com/a/60696378

tests/lint: prevent typo from tree.c 1.264 from happening again

lint: remove wrong warning about wrong initializer type

The following code is valid:

int valid = {{{ 3 }}};

C90 3.5.7 and C99 6.7.8 both say that the "initializer for a scalar
shall be a single expression, optionally enclosed in braces". They
don't put any upper bound on the amount of braces, not even in the
"Translation limits" section.

tests/lint: test initialization using string literals

The errors in line 74 and 75 of the test are wrong. Everything is fine
there. The bug lies in init_array_using_string, try to see if you can
spot it, neither GCC 9.3.0 nor Clang 8.0.1 could.

lint: in strict C mode, warn about initialization with '[a ... b]'

https://gcc.gnu.org/onlinedocs/gcc/Case-Ranges.html

lint: fix null pointer dereference on parse error

Fixes PR bin/22119.

lint: add test to demonstrate that PR bin/20264 has been fixed

lint: add another test for C99 initializers

lint: warn about mismatch in getopt handling

lint: add more tests for system headers in strict bool mode

lint: add tests for newly added messages for strict bool mode

lint: add test for triggering assertion failures in lint1

lint: add test for treating _Bool as non-scalar type

This strict mode is not yet implemented. The plan is to use it for
usr.bin/make, to get rid of the many possible variants of defining the
Boolean type in make.h. These variants did find some bugs, but not
reliably so. Using static analysis seems more promising for this.

In an early stage of developing this test, lint1 crashed in the enum
definition in line 213, where the node for the '?:' had been NULL. This
can happen in other situations as well, such as with syntax errors, but
these should be rare, as lint is usually only run if the compiler has
accepted the source code. Still, there should not be any assertion
failures while running lint1.

lint: demonstrate wrong handling of conversion to _Bool

lint: add a test for each message produced by lint1

Having a test for each message ensures that upcoming refactorings don't
break the basic functionality. Adding the tests will also discover
previously unknown bugs in lint.

The tests ensure that every lint message can actually be triggered, and
they demonstrate how to do so. Having a separate file for each test
leaves enough space for documenting historical anecdotes, rationale or
edge cases, keeping them away from the source code.

The interesting details of this commit are in Makefile and
t_integration.sh. All other files are just auto-generated.

When running the tests as part of ATF, they are packed together as a
single test case. Conceptually, it would have been better to have each
test as a separate test case, but ATF quickly becomes very slow as soon
as a test program defines too many test cases, and 50 is already too
many. The time complexity is O(n^2), not O(n) as one would expect.
It's the same problem as in tests/usr.bin/make, which has over 300 test
cases as well.

lint: demonstrate bug in handling of nested C9X struct initializers

lint: fix segmentation fault when checking returned enum types (211)

lint: check that in "if (cond)", cond is scalar

lint: add test for old style function arguments

lint1: add forgotten tests

lint1: enable test cvt_constant

This test had never been enabled. In t_integration.sh 1.3 from
2014-04-17 it was supposed to be enabled, but due to a line continuation
backslash, the words "test_case check_valid" ended up as the description
of the previous test, cvt_in_ternary.

While here, add the expected test output for d_struct_init_nested to
FILES.

lint1: add test for initializing nested structs

Discovered in var.c 1.774 from 2020-12-28.

lint: for tests with output, ensure that the output matches

lint: sort tests by name

add builtin_offsetof

add a test for a typeof cast

branches: 1.13.2;
Add union cast test

new test for struct that only has anon members, and that the size of struct
is computer right.

branches: 1.11.2;
Add an anonymous struct test

new test

new c99 init test found by xorg's Iconify.c

new test.

add one more test

add test for typename as a function param

test for c99 flexible packed arrays

Add one more test

add more tests

branches: 1.2.2;
Handle another declaration after statement case for lint in c99 mode.
Add the corresponding testcase.

branches: 1.1.2; 1.1.4;
Deprecate tests/util.

lint: normalize whitespace

lint: add detail to message about obsolete identifier list

tests/lint: allow empty lines in .exp-ln files

The generated .ln files neither contain spaces nor empty lines. To make
the input more human-readable, allow empty lines in the expected .ln
files.

branches: 1.15.2;
tests/lint: sort multiple diagnostics per line chronologically

For now, the chronologic order is not enforced but has to be established
manually, for example by removing all 'expect' comment lines and
regenerating them with 'accept.sh -u'.

While here, clean up a few instances that came up when regenerating the
'expect' comments, such as wrong indentation or needless deviation from
the 'expect+1' form.

tests/lint: automate accepting changed test results

tests/lint: only overwrite .exp files if the output actually changes

tests/lint: do not overwrite expected files that only differ in spaces

tests/lint: add quotes around placeholders in a few messages

tests/lint: remove .exp files, as they have become redundant

Now that each lint1 test lists all generated diagnostics as 'expect'
comments, the information from the .exp files is no longer needed. The
only information that gets lost is the order of the diagnostics, which
is mostly relevant for paired messages like 'inconsistent definition' +
'previous definition was here'.

lint: in C99 mode, allow trailing comma in enum declarations

Adjust the test to be run in C90 mode instead of traditional mode, since
traditional C didn't have enums.

tests/lint: add tests for several messages

tests/lint: remove unintended debugging output

tests/lint: fix check for expected message in msg tests

tests/lint: clean up accept.sh, document test for removed assertion

tests/lint: test emitting 128-bit integer types for lint2

tests/lint: when accepting test results, skip crashes

tests/lint: suppress ShellCheck warnings for intentional violations

The undeclared variables are generated by the AWK program.
The variable 'flags' must be split into words at exactly this point.

tests/lint: add 'make accept' to update the expected output

lint: in C23 mode, do not warn about an empty parameter list

lint: s/illegal/invalid/g

Lint does not provide legal advice.

lint: remove no-op variant of the unary '&' operator

Neither K&R 1978 nor any of the C standards mentions that &function or
&array would be a no-op. This no-op behavior produced wrong warnings in
sbin/gpt.

tests/lint: add a few more tests to increase code coverage

branches: 1.7.2;
tests/lint: show that in C23 mode, bool is not yet defined

The tests in C11 and C23 mode look the same right now but will change
soon.

The warnings in the C11 test disappeared because after the first error,
warnings about unused variables are suppressed by check_variable_usage,
as they are often wrong.

tests/lint: sort multiple diagnostics per line chronologically

For now, the chronologic order is not enforced but has to be established
manually, for example by removing all 'expect' comment lines and
regenerating them with 'accept.sh -u'.

While here, clean up a few instances that came up when regenerating the
'expect' comments, such as wrong indentation or needless deviation from
the 'expect+1' form.

lint: make '_Static_assert' only available in C11 or C23 mode

tests/lint: test declarations in C11 and C23

lint: in C23 mode, recognize the keyword 'thread_local'

lint: reject _Noreturn if it occurs in invalid places

C11 introduced _Noreturn as a function-specifier, not as a type
attribute. The latter may occur in more places.

tests/lint: add test for _Noreturn from C11

lint: warn about function definitions without header declaration

The existing warning was only issued for function declarations, not for
function definitions.

The interesting change in the tests is in msg_351.c. Many other tests
use non-static functions due to their syntactic brevity. In these
tests, the warning is disabled individually, to allow new functions to
be added without generating warning 351.

tests/lint: merge duplicate tests for C11 _Atomic

lint: add support for C11 '_Atomic' as atomic-type-specifier

Following the C11 grammar, the keyword '_Atomic' needs to be a separate
syntactic category, to avoid further conflicts in the grammar.

The two newly added conflicts in the grammar would come into play when
mixing traditional C with C11, in a type name without an implicit 'int'.
If the type '_Atomic(int)*' were parsed as '_Atomic int(int)*', the
trailing '*' would be a syntax error.

lint: add support for the C11 type qualifier '_Atomic'

That keyword can be used as a type specifier as well, support for that
will be added later.

tests/lint: test _Atomic, added in C11

lint: since C99, a non-void function must return a value

lint: clean up wording in diagnostics

Use the term 'parameter' as defined in C99 3.15.

lint: warn about function definitions without header declaration

The existing warning was only issued for function declarations, not for
function definitions.

The interesting change in the tests is in msg_351.c. Many other tests
use non-static functions due to their syntactic brevity. In these
tests, the warning is disabled individually, to allow new functions to
be added without generating warning 351.

tests/lint: merge duplicate tests for C11 _Atomic

lint: warn about extern declarations outside headers

https://mail-index.netbsd.org/tech-userlevel/2023/03/15/msg013727.html

tests/lint: fix typo in comment

lint: add quotes around placeholders for the remaining messages

Reword some of the messages slightly, exchanging brevity for clarity.

Message 138 is kept as-is, as it is not yet covered by any tests.

Message 240 is kep as-is, as it is unreachable.

tests/lint: make 'expect+-' comments stricter

Previously, the expectations from these comments were already satisfied
if the expectation occurred somewhere in the actual message from lint.
This meant that the prefix 'error:' or 'warning:' could be omitted from
the 'expect' comment. These omissions were hard to see in a manual
review. Now any omissions must be visually marked with '...'.

The test msg_342 now reports its messages properly as being in the file
msg_342.c, rather than msg_341.c. This had been a copy-and-paste
mistake.

tests/lint: expect complete messages in feature tests

Previously, the tests contained many comments like /* expect: 123 */,
which were useless to a casual reader since nobody is expected to learn
lint's message IDs by heart. Replace these with the complete
diagnostics, to show what lint is complaining about.

The tests named msg_*.c have been left unmodified since they mention the
full message text in their header comment.

No functional change.

tests/lint: fix test c11_generic_expression on ILP32

These platforms don't provide __uint128_t, at least not in lint.

The exact data type does not matter in this test, it just has to be
different from 'int'.

tests/lint: document why lint does not check _Generic selections

lint: make _Generic a primary-expression

C11 says so, and unless the _Generic expression was wrapped in
parentheses, it was not possible before to use it as a function call
expression.

tests/lint: demonstrate that _Generic must be a primary_expression

lint: only accept assignment-expression in _Generic

That's what C11 says.

lint: fix parsing of _Generic selection expressions

Previously, lint accepted comma-expressions where only
assignment-expressions are allowed.

This change does not make a difference in practice though since lint is
usually only run on source code that properly compiles. Nevertheless,
rather be precise and accurate since the grammar might some day be
reused on less reliable input.

lint: fix type comparison in _Generic selection expressions

In the newly added test comma_expression, there were two distinct type
objects for the tspec DOUBLE.

lint: fix result type of _Generic expressions

tests/lint: add test for _Generic with incompatible return types

lint: fix option -Ac11, add test for _Generic

Previously, selecting the option -Ac11 allowed features from C11 but at
the same time prohibited 'long long', which was added in C99. This was
caused by the option -s, which is interpreted as "allow features from
C90, but no later".

The test for _Generic, which has been added in C11, demonstrates that
the current implementation is broken. Lint currently thinks that the
return type of a _Generic selection is the type of the expression, but
it really is the type of the selected expression. In the current tests,
this is always 'const char *', but C11 does not require that the types
of a generic selection are compatible.

tests/lint: remove .exp files, as they have become redundant

Now that each lint1 test lists all generated diagnostics as 'expect'
comments, the information from the .exp files is no longer needed. The
only information that gets lost is the order of the diagnostics, which
is mostly relevant for paired messages like 'inconsistent definition' +
'previous definition was here'.

tests/lint: expect complete messages in feature tests

Previously, the tests contained many comments like /* expect: 123 */,
which were useless to a casual reader since nobody is expected to learn
lint's message IDs by heart. Replace these with the complete
diagnostics, to show what lint is complaining about.

The tests named msg_*.c have been left unmodified since they mention the
full message text in their header comment.

No functional change.

lint: add quotes around placeholder in message 214

function '%s' expects to return value

lint: make _Generic a primary-expression

C11 says so, and unless the _Generic expression was wrapped in
parentheses, it was not possible before to use it as a function call
expression.

tests/lint: demonstrate that _Generic must be a primary_expression

lint: fix parsing of _Generic selection expressions

Previously, lint accepted comma-expressions where only
assignment-expressions are allowed.

This change does not make a difference in practice though since lint is
usually only run on source code that properly compiles. Nevertheless,
rather be precise and accurate since the grammar might some day be
reused on less reliable input.

lint: fix type comparison in _Generic selection expressions

In the newly added test comma_expression, there were two distinct type
objects for the tspec DOUBLE.

lint: fix result type of _Generic expressions

tests/lint: add test for _Generic with incompatible return types

lint: fix option -Ac11, add test for _Generic

Previously, selecting the option -Ac11 allowed features from C11 but at
the same time prohibited 'long long', which was added in C99. This was
caused by the option -s, which is interpreted as "allow features from
C90, but no later".

The test for _Generic, which has been added in C11, demonstrates that
the current implementation is broken. Lint currently thinks that the
return type of a _Generic selection is the type of the expression, but
it really is the type of the selected expression. In the current tests,
this is always 'const char *', but C11 does not require that the types
of a generic selection are compatible.

lint: in C23 mode, do not warn about an empty parameter list

tests/lint: add a few more tests to increase code coverage

branches: 1.16.2;
lint: don't warn about unused C23 [[maybe_unused]] parameters

lint: accept C23 [[fallthrough]] statements

Needed by bind9/getaddresses.c:137.

lint: accept C23 attributes at the beginning of a type declaration

The switch to GCC 12 brings support for C23, and localtime.c uses it to
mark [[maybe_unused]] parameters.

For now, accept C23 attributes independently from the language level. In
the end, the whole tree with the exception of the tools should be
switched to C23 mode instead of the current C99 mode.

For now, don't actually mark the argument as possibly unused, as lint
currently ignores __attribute__((__unused__)) as well.

lint: parse but otherwise ignore C23 attributes

The C23 attributes are only parsed before an expression in an expression
statement, as a proof of concept. Other places will follow later.

lint: in C23 mode, allow storage classes in compound literals

lint: in C23 mode, support the nullptr constant

lint: in C23 mode, support the keywords 'bool', 'false' and 'true'

tests/lint: show that in C23 mode, bool is not yet defined

The tests in C11 and C23 mode look the same right now but will change
soon.

The warnings in the C11 test disappeared because after the first error,
warnings about unused variables are suppressed by check_variable_usage,
as they are often wrong.

tests/lint: sort multiple diagnostics per line chronologically

For now, the chronologic order is not enforced but has to be established
manually, for example by removing all 'expect' comment lines and
regenerating them with 'accept.sh -u'.

While here, clean up a few instances that came up when regenerating the
'expect' comments, such as wrong indentation or needless deviation from
the 'expect+1' form.

tests/lint: test declarations in C11 and C23

lint: allow 'thread_local' to be combined with 'static'

lint: allow 'extern' and 'thread_local' to be combined

tests/lint: test 'extern thread_local' storage classes

Seen in external/mpl/bind/dist/lib/isc/pthreads/include/isc/thread.h:32.

lint: clean up comments, add a test for the '?:' operator

lint: in C23 mode, recognize the keyword 'thread_local'

tests/lint: add C23 tests

tests/lint: add a few more tests to increase code coverage

branches: 1.3.2;
lint: make diagnostics about ANSI C more international

lint: warn about extern declarations outside headers

https://mail-index.netbsd.org/tech-userlevel/2023/03/15/msg013727.html

tests/lint: cover every code line in the grammar

tests/lint: remove .exp files, as they have become redundant

Now that each lint1 test lists all generated diagnostics as 'expect'
comments, the information from the .exp files is no longer needed. The
only information that gets lost is the order of the diagnostics, which
is mostly relevant for paired messages like 'inconsistent definition' +
'previous definition was here'.

tests/lint: cover every code line in the grammar

tests/lint: merge duplicate tests for C11 _Atomic

lint: add support for C11 '_Atomic' as atomic-type-specifier

Following the C11 grammar, the keyword '_Atomic' needs to be a separate
syntactic category, to avoid further conflicts in the grammar.

The two newly added conflicts in the grammar would come into play when
mixing traditional C with C11, in a type name without an implicit 'int'.
If the type '_Atomic(int)*' were parsed as '_Atomic int(int)*', the
trailing '*' would be a syntax error.

lint: add support for the C11 type qualifier '_Atomic'

That keyword can be used as a type specifier as well, support for that
will be added later.

tests/lint: test _Atomic, added in C11

lint: warn about function definitions without header declaration

The existing warning was only issued for function declarations, not for
function definitions.

The interesting change in the tests is in msg_351.c. Many other tests
use non-static functions due to their syntactic brevity. In these
tests, the warning is disabled individually, to allow new functions to
be added without generating warning 351.

lint: add quotes around placeholders in 4 messages

tests/lint: clean up accept.sh, document test for removed assertion

tests/lint: fix check-expect.lua for empty .exp file

An absent .exp file is equivalent to an empty .exp file. In neither of
these cases must the corresponding .c file declare any expected
diagnostics.

lint: remove outdated assertion

Since err.c 1.12 from 2000-07-06, lint allows to suppress individual
error messages. Suppressed error messages do not increment nerr.
Keeping nerr at 0 had triggered the assertion.

tests/lint: add test for suppressing errors in strict bool mode

lint: remove outdated assertion

Since err.c 1.12 from 2000-07-06, lint allows to suppress individual
error messages. Suppressed error messages do not increment nerr.
Keeping nerr at 0 had triggered the assertion.

tests/lint: add test for suppressing errors in strict bool mode

tests/lint: remove redundant tests

The names of the tests were misleading: 'recursive' should have been
'nested', and the interesting topic in the 'cast' tests was not the cast
but the pointer dereference.

tests/lint: encode the array length in the diagnostic

lint: fix initialization of array of unknown size

The size of the resulting array was computed wrong.

tests/lint: add test for array subscripts in C99 initialization

tests/lint: remove .exp files, as they have become redundant

Now that each lint1 test lists all generated diagnostics as 'expect'
comments, the information from the .exp files is no longer needed. The
only information that gets lost is the order of the diagnostics, which
is mostly relevant for paired messages like 'inconsistent definition' +
'previous definition was here'.

tests/lint: encode the array length in the diagnostic

lint: fix initialization of array of unknown size

The size of the resulting array was computed wrong.

tests/lint: add test for array subscripts in C99 initialization

tests/lint: remove redundant tests

The names of the tests were misleading: 'recursive' should have been
'nested', and the interesting topic in the 'cast' tests was not the cast
but the pointer dereference.

tests/lint: expect complete messages in feature tests

Previously, the tests contained many comments like /* expect: 123 */,
which were useless to a casual reader since nobody is expected to learn
lint's message IDs by heart. Replace these with the complete
diagnostics, to show what lint is complaining about.

The tests named msg_*.c have been left unmodified since they mention the
full message text in their header comment.

No functional change.

tests/lint: test syntax error in initialization using designator

This test prepares the upcoming refactoring of the grammar.

tests/lint: remove .exp files, as they have become redundant

Now that each lint1 test lists all generated diagnostics as 'expect'
comments, the information from the .exp files is no longer needed. The
only information that gets lost is the order of the diagnostics, which
is mostly relevant for paired messages like 'inconsistent definition' +
'previous definition was here'.

tests/lint: expect complete messages in feature tests

Previously, the tests contained many comments like /* expect: 123 */,
which were useless to a casual reader since nobody is expected to learn
lint's message IDs by heart. Replace these with the complete
diagnostics, to show what lint is complaining about.

The tests named msg_*.c have been left unmodified since they mention the
full message text in their header comment.

No functional change.

tests/lint: test syntax error in initialization using designator

This test prepares the upcoming refactoring of the grammar.

lint: normalize whitespace

tests/lint: run lint1 tests in one fell swoop

This generates fewer details in the ATF test reports, as the
platform-specific tests that are skipped are not mentioned individually.

branches: 1.12.2;
tests/lint: enforce diagnostics to be listed in chronologic order

While here, fix the tests on uchar platforms.

tests/lint: sort diagnostics in ilp32 tests chronologically

tests/lint: sort multiple diagnostics per line chronologically

For now, the chronologic order is not enforced but has to be established
manually, for example by removing all 'expect' comment lines and
regenerating them with 'accept.sh -u'.

While here, clean up a few instances that came up when regenerating the
'expect' comments, such as wrong indentation or needless deviation from
the 'expect+1' form.

tests/lint: test integer constants in different language levels

tests/lint: test parsing of preprocessing directives

tests/lint: fix a few ilp32 tests

tests/lint: automate accepting changed test results

tests/lint: ensure consistent preprocessor filenames in tests

The deviations often happen when copying or renaming tests.

lint: clean up typos

tests/lint: fix preprocessor line number validation

When running the tests via ATF, the filename was an absolute filename,
while the preprocessing line in the test file uses a relative filename.
These two didn't match.

tests/lint: add quotes around placeholders in a few messages

tests/lint: move check-expect.lua to tests/lint1

It is only used for testing lint1, not for lint2 or xlint.

lint: warn about function definitions without header declaration

The existing warning was only issued for function declarations, not for
function definitions.

The interesting change in the tests is in msg_351.c. Many other tests
use non-static functions due to their syntactic brevity. In these
tests, the warning is disabled individually, to allow new functions to
be added without generating warning 351.

tests/lint: extend tests for sizeof and alignof

lint: make alignof(incomplete enum) an error

tests/lint: add more tests for sizeof, offsetof, alignof

lint: add quotes around placeholders for the remaining messages

Reword some of the messages slightly, exchanging brevity for clarity.

Message 138 is kept as-is, as it is not yet covered by any tests.

Message 240 is kep as-is, as it is unreachable.

lint: merge duplicate grammar rules for __alignof__ expr

This allows expressions like '__alignof__(ptr)->member', just as with
'sizeof'.

The upper rule in the grammar was preferred over the lower rule since it
shifted the T_LPAREN instead of reducing unary_expression. Its
implementation invoked undefined behavior if the expression was NULL
since it didn't assign anything to $$.

tests/lint: add more tests for __alignof__

lint: add support for __alignof__ expr, a GCC extension

Seen in lib/libc/gmon/gmon.c:153.

lint: fix support for __alignof__, add support for __alignof

Broken since lex.c 1.129 from yesterday.

tests/lint: adjust tests to reflect missing support of __alignof__

The change in lex.c 1.129 attempted to add support for __alignof, in
addition to the existing support for __alignof__. It failed by removing
support for __alignof__, while allowing the plain 'alignof' instead.

lint: add common header for all tests

For those tests that didn't use GCC-style line markers such as "# 2",
the line numbers of the diagnostics stay the same. This is purely
conincidental. Before, the 3 lines came from lint's built-in
definitions (see 'builtins' in main1.c), and line number counting
continued as if nothing had happened, making the first line of the
actual file line 4. These 3 built-in lines are now replaced with 3
lines of file header.

branches: 1.1.2;
Deprecate tests/util.

tests/lint: remove .exp files, as they have become redundant

Now that each lint1 test lists all generated diagnostics as 'expect'
comments, the information from the .exp files is no longer needed. The
only information that gets lost is the order of the diagnostics, which
is mostly relevant for paired messages like 'inconsistent definition' +
'previous definition was here'.

lint: merge duplicate grammar rules for __alignof__ expr

This allows expressions like '__alignof__(ptr)->member', just as with
'sizeof'.

The upper rule in the grammar was preferred over the lower rule since it
shifted the T_LPAREN instead of reducing unary_expression. Its
implementation invoked undefined behavior if the expression was NULL
since it didn't assign anything to $$.

tests/lint: add more tests for __alignof__

lint: add support for __alignof__ expr, a GCC extension

Seen in lib/libc/gmon/gmon.c:153.

lint: fix support for __alignof__, add support for __alignof

Broken since lex.c 1.129 from yesterday.

tests/lint: adjust tests to reflect missing support of __alignof__

The change in lex.c 1.129 attempted to add support for __alignof, in
addition to the existing support for __alignof__. It failed by removing
support for __alignof__, while allowing the plain 'alignof' instead.

lint: allow complex offsetof(type, member-designator)

Both GCC 11 and Clang 8 accept member-designators that are not
identifiers but designator sequences, such as in 'offsetof(struct stat,
st_atim.tv_sec)', so make lint accept them as well.

lint: add common header for all tests

For those tests that didn't use GCC-style line markers such as "# 2",
the line numbers of the diagnostics stay the same. This is purely
conincidental. Before, the 3 lines came from lint's built-in
definitions (see 'builtins' in main1.c), and line number counting
continued as if nothing had happened, making the first line of the
actual file line 4. These 3 built-in lines are now replaced with 3
lines of file header.

branches: 1.1.2; 1.1.4;
new test

lint: remove noclass_declmods from grammar

That rule was hard to understand since it contained clrtyp but not the
corresponding deftyp. It's easier to read when a grammar rule contains
both clrtyp and deftyp in the same line.

C99 does not mention the term 'decl-modifier' anywhere, and in fact the
only thing that this grammar rule allowed was a type-qualifier-list.
The new name better reflect this.

No functional change.

lint: add common header for all tests

For those tests that didn't use GCC-style line markers such as "# 2",
the line numbers of the diagnostics stay the same. This is purely
conincidental. Before, the 3 lines came from lint's built-in
definitions (see 'builtins' in main1.c), and line number counting
continued as if nothing had happened, making the first line of the
actual file line 4. These 3 built-in lines are now replaced with 3
lines of file header.

lint: normalize whitespace in tests

Add an anonymous struct test

lint: warn about extern declarations outside headers

https://mail-index.netbsd.org/tech-userlevel/2023/03/15/msg013727.html

lint: clean up some of the C99 tests

Several C99 tests do not actually test C99 features but instead GCC
features. All these tests should be double-checked again.

In some other tests, split the initializers into more lines, which makes
it easier to read the debug log corresponding to these tests. This will
be necessary for reworking the initializer code to actually conform to
C99.

lint: format tests in a common style

The lint tests do not focus on the whitespace since that is the most
boring part of code style. Therefore, format the tests to be readable
by following share/misc/style as close as possible.

lint: add common header for all tests

For those tests that didn't use GCC-style line markers such as "# 2",
the line numbers of the diagnostics stay the same. This is purely
conincidental. Before, the 3 lines came from lint's built-in
definitions (see 'builtins' in main1.c), and line number counting
continued as if nothing had happened, making the first line of the
actual file line 4. These 3 built-in lines are now replaced with 3
lines of file header.

branches: 1.1.2;
new test for struct that only has anon members, and that the size of struct
is computer right.

tests/lint: clean up tests for C99 bool

lint: warn about extern declarations outside headers

https://mail-index.netbsd.org/tech-userlevel/2023/03/15/msg013727.html

tests/lint: update comment to reality

tests/lint: expect complete messages in feature tests

Previously, the tests contained many comments like /* expect: 123 */,
which were useless to a casual reader since nobody is expected to learn
lint's message IDs by heart. Replace these with the complete
diagnostics, to show what lint is complaining about.

The tests named msg_*.c have been left unmodified since they mention the
full message text in their header comment.

No functional change.

lint: rewrite handling of initializations, fixing several bugs

The previous implementation had a wrong model of how initialization
happens in C99, its assertions failed in all kind of edge cases and it
was not possible to fix the remaining bugs one at a time without running
into even more obscure assertion failures.

The debug logging was detailed but did not help to clarify the
situation. After about 20 failed attempts at fixing the small details I
decided to start all over and rewrite the initialization code from
scratch. I left the low-level parts of handling designators, the code
that is independent of brace_level and the high-level parts of how the
parser calls into this module. Everything else is completely new.

The concept of a brace level stays since that is how C99 describes
initialization. The previous code could not handle multi-level
designations (see d_init_pop_member.c). There are no more assertion
failures in the initialization code.

Some TODO comments have been left in the tests to keep the line numbers
the same in this commit. These will be cleaned up in a follow-up
commit.

The new implementation does not handle initialization with "missing"
braces. This is an edge case that both GCC and Clang warn about, so it
is not widely used. If necessary, it may be added later.

The new implementation does not use any global variables in the vast
majority of the functions, to make all dependencies and possible
modifications obvious.

lint: force each test to declare the expected diagnostics

By listing the expected diagnostics directly at the code that triggers
the diagnostics, it is easier to cross-check whether the diagnostics
make sense.

No functional change to lint itself.

lint: explain missing error for _Bool constant expressions

lint: fix conversion of non-constant scalar to _Bool

lint: fix conversion of constant expressions to _Bool

lint: add test for converting non-constant expressions to _Bool

lint: demonstrate wrong handling of conversion to _Bool

tests/lint: remove .exp files, as they have become redundant

Now that each lint1 test lists all generated diagnostics as 'expect'
comments, the information from the .exp files is no longer needed. The
only information that gets lost is the order of the diagnostics, which
is mostly relevant for paired messages like 'inconsistent definition' +
'previous definition was here'.

tests/lint: update comment to reality

tests/lint: expect complete messages in feature tests

Previously, the tests contained many comments like /* expect: 123 */,
which were useless to a casual reader since nobody is expected to learn
lint's message IDs by heart. Replace these with the complete
diagnostics, to show what lint is complaining about.

The tests named msg_*.c have been left unmodified since they mention the
full message text in their header comment.

No functional change.

lint: prefix error messages with 'error:'

This makes it easier to find these errors in the build logs.

lint: explain missing error for _Bool constant expressions

lint: fix conversion of non-constant scalar to _Bool

lint: fix conversion of constant expressions to _Bool

lint: add test for converting non-constant expressions to _Bool

lint: demonstrate wrong handling of conversion to _Bool

lint: disable message 207 about 'loop not entered at top'

The purpose of the message is unclear, and it produces several warnings
in legitimate code.

lint: s/illegal/invalid/g

Lint does not provide legal advice.

lint: remove now-unnecessary CONSTCOND comments

lint: do not warn about constant operand of '!'

Like its related warning about a constant condition, the purpose of this
warning is unclear, and suppressing the warning requires special lint
comments, thus cluttering the code.

The message itself is still kept in err.c to keep the '-X 239' option
valid. These LINTFLAGS will be removed in a follow-up commit.

The lint comments /* CONSTCOND */, as well as its more verbose forms /*
CONSTANTCOND */ and /* CONSTANTCONDITION */ are no longer needed and can
be removed.

lint: remove warning about 'constant in conditional context'

In a full NetBSD build, this warning occurs about 2400 times, making it
the top 9 warning overall. There is no evidence though that this
warning detects any real bugs, so the noise it makes is not warranted.

In this first step, the warning is still listed in the lint(7) manual
page, as removing it from there would immediately make all places with
"LINTFLAGS += -X 161" fail. These '-X 161' flags cannot be removed
first because then, the warning would step in and make the build fail.

The next step is to clean up the "-X 161" options from all LINTFLAGS,
and then the final step is to remove the warning from err.c.

lint: add more details to 'statement not reached' message

In lib/libcompat/regexp/regexp.c, the FAIL macro expands to a compound
statement containing a function call statement and a return statement,
and the macro invocation is followed by a semicolon, forming an extra
empty statement. Which of these statements is unreachable now becomes
clear from the diagnostic, without having to inspect the preprocessed
source code.

branches: 1.50.2;
lint: in strict bool mode, allow do-while-0

Even though 0 is not a boolean constant, allow this common idiom, to
help in those cases where the C preprocessor used by lint does not mark
tokens as coming from system headers (Clang).

tests/lint: clean up tests for strict bool mode

tests/lint: sync comments in test for strict bool mode with reality

lint: in strict bool mode, allow 'a & b' in controlling expressions

Previously, the expression 'a & b' was only treated as bool if 'a' had
enum type. This didn't cover cases in which bit masks were implemented
using integer types instead of enum sets.

tests/lint: test '&' for non-enum types in strict bool mode

lint: clean up comments

No functional change.

lint: distinguish between arguments and parameters

lint: clean up wording in diagnostics

Use the term 'parameter' as defined in C99 3.15.

lint: remove redundant '#' after 'argument' in diagnostics

tests/lint: clean up tests for C99 bool

lint: warn about extern declarations outside headers

https://mail-index.netbsd.org/tech-userlevel/2023/03/15/msg013727.html

lint: add quotes around placeholders for the remaining messages

Reword some of the messages slightly, exchanging brevity for clarity.

Message 138 is kept as-is, as it is not yet covered by any tests.

Message 240 is kep as-is, as it is unreachable.

lint: add quotes around placeholders in 4 messages

lint: encode lifetime of allocated memory in the function names

No functional change.

tests/lint: expect complete messages in feature tests

Previously, the tests contained many comments like /* expect: 123 */,
which were useless to a casual reader since nobody is expected to learn
lint's message IDs by heart. Replace these with the complete
diagnostics, to show what lint is complaining about.

The tests named msg_*.c have been left unmodified since they mention the
full message text in their header comment.

No functional change.

tests/lint: fix negation in explanation for strict bool mode

lint: fix check for function calls in strict bool mode

Previously, if a function call occurred in the controlling expression,
its return type could be any scalar, not just bool. This was against
the goal of strict bool mode, which makes bool a separate and
incompabile type to all other types. For example, it would allow
controlling expressions like 'strcmp(a, b)' without the usual '!= 0',
but only if at least one of 'a' and 'b' came from a macro definition
from a system header.

The fix is that the decision of whether the type of the controlling
expression may be scalar is no longer based on the operand types but on
the main operator of the controlling expression.

lint: fix wrong error message in strict bool mode

This fix only affects the last token before a macro, as well as the last
token in the expanded macro.

tests/lint: explain the missing error message in strict bool mode

There are 2 separate bugs that lead to the missing error message.

The first bug is that when parsing a name, the information about whether
that name comes from a system header is not properly recorded for the
last token before switching from or to a system header.

The second bug is that for determining whether the type of a function
call expression is relaxed, the types of the function call arguments are
taken into account, even though the type only depends on the function
itself. The same idea applies to the operators '<<' and '>>', as their
result type only depends on the left operand, at least since C90.

tests/lint: demonstrate missing errors for strict bool mode

Seen in bin/echo/echo.c.

lint: in strict bool mode, continue after error message

If a controlling expression is not of type bool but of any other scalar
type, keep the expression. Its value is still useful for control flow
analysis.

This prevents an assertion failure when running lint on the generated
scan.c, which contains a "while (1)" that does not stem from a system
header. If it did, lint would accept it, see tn_from_system_header. But
"scan.c" is not considered a system header. Maybe lint's definition of
a system header needs to be revisited.

After fixing this, there is another assertion failure though, so scan.c
is not yet ready to be inspected by lint.

lint: no special check for unary operators in strict bool mode

All interesting constellations regarding unary operators are already
covered by the simple model from ops.def.

No functional change.

tests/lint: one comment per expected diagnostic

This makes it possible to check for diagnostics that contain commas.

tests/lint: fix outdated comments

lint: fix reachability computation in if statements

Previously, only loop statements were considered for reachability. This
ignored the possibility of an early return in an if statement, or
unreachable branches.

tests/lint: sync redundant documentation in test for strict bool mode

lint: in strict bool mode, check initialization as well

C99 6.7.8p11 says for initialization that "the same type constraints and
conversions as for simple assignments apply", so actually apply them.
(I had just forgotten this "operator" when I first implemented strict
bool mode.)

tests/lint: test initialization in strict bool mode

I somehow forgot to list INIT as one of the operators in
is_assignment_bool_or_other.

tests/lint: allow 'expect' comments to refer to other lines

This allows /* expect+1: ... */ to refer to the following line, as well
as /* expect-1: ... */ to refer to the previous line. This avoids
horizontal scrolling to see the expectations, it also allows these
expectations comments to be more verbose, mentioning the whole
diagnostic in many cases.

The 'expect' comments don't need to be at the end of a line anymore
since that was rather surprising. The one 'expect' comment that had not
been at the end of the line was in d_c99_bool_strict.c and was not
intended to be ignored.

lint: do not warn about 'do { ... } while (false)' in strict bool mode

lint: add test for 'do { ... } while (false)' in strict bool mode

Right now, this variant of the popular macro pattern is flagged as
needing a /*CONSTCOND*/ annotation. As with 'do { ... } while (0)',
there is nothing wrong with this pattern, therefore there should be no
warning.

lint: enable heuristics in test for strict bool mode

This is a preparation for allowing 'do { ... } while (false)', in
addition to the commonly used 'do { ... } while (0)', without declaring
the controlling expression /*CONSTCOND*/.

lint: add test for using a bool as array index in strict bool mode

lint: add more tests for system headers in strict bool mode

lint: add test for macro from system header in strict bool mode

Seen in usr.bin/make/meta.c:1670: FD_ZERO(&readfds). These macros
cannot be fixed since system headers must not include <stdbool.h>.
Therefore INT constants should be accepted as controlling expressions as
well.

lint: in strict bool mode, don't treat bool as arithmetic type

lint: explain failing test case in strict bool mode

lint: demonstrate wrong error message in strict bool mode

lint: add missing warning for bool() == int

lint: remove redundant calls to before_conversion

lint: add test for missing check in strict bool mode

lint: in strict bool mode, integer constants do not have type bool

Previously, lint1 allowed integer constants such as 0 and 1 to be used
as bool constants. This was only half-baked since after fixing all
error messages from that strict mode, there may still be integer
literals in the code that should be replaced with true or false. This
would stop a migration from int to bool in the middle, leaving
inconsistent code around.

To find the remaining type inconsistencies, treat integers and bool as
completely incompatible, even for compile time constants.

lint: prepare to make strict bool mode even stricter

Currently, strict bool mode still allows integer constant expressions to
be converted implicitly to bool. This is something that other languages
such as Go, Java, C#, Pascal don't allow.

By providing a custom implementation of <stdbool.h> that defines false
and true to custom bool constant identifiers, lint will cover these
cases as well.

To prepare for this, reword the rules and restructure the tests in
d_c99_bool_strict.c.

lint: add test for bool bit fields as operands of '|'

lint: in strict bool mode, allow bool as operands of the comma operator

lint: demonstrate wrong message for comma operator

lint: add new check for strict bool mode

In strict bool mode, bool is considered incompatible with all other
scalar types, just as in Java, C#, Pascal.

The controlling expressions in if statements, while loops, for loops and
the '?:' operator must be of type bool. The logical operators work on
bool instead of int, the bitwise operators accept both integer and bool.
The arithmetic operators don't accept bool.

Since <stdbool.h> implements bool using C preprocessor macros instead of
predefining the identifiers "true" and "false", the integer constants 0
and 1 may be used in all contexts that require a bool expression.
Except from these, no implicit conversion between bool and scalar types
is allowed.

See usr.bin/tests/xlint/lint1/d_c99_bool_strict.c for more details.

The command line option -T has been chosen because all obvious choices
(-b or -B for bool, -s or -S for strict) are already in use. The -T may
stand for "types are checked strictly".

The default behavior of lint doesn't change. The strict bool check is
purely optional.

An example program for strict bool mode is usr.bin/make, which has been
using explicit comparisons such as p != NULL, ch != '\0' or n > 0 in
most places for a long time now, even before the refactoring in 2020.

lint: extend test for strict _Bool handling

There is no danger in allowing (flags & FLAG) as a controlling
expression, provided that it is immediately compared to zero, such as in
an if statement or as the operand of a logical operator.

lint: add enum flags to the test about strict boolean mode

lint: add test for treating _Bool as non-scalar type

This strict mode is not yet implemented. The plan is to use it for
usr.bin/make, to get rid of the many possible variants of defining the
Boolean type in make.h. These variants did find some bugs, but not
reliably so. Using static analysis seems more promising for this.

In an early stage of developing this test, lint1 crashed in the enum
definition in line 213, where the node for the '?:' had been NULL. This
can happen in other situations as well, such as with syntax errors, but
these should be rare, as lint is usually only run if the compiler has
accepted the source code. Still, there should not be any assertion
failures while running lint1.

tests/lint: remove .exp files, as they have become redundant

Now that each lint1 test lists all generated diagnostics as 'expect'
comments, the information from the .exp files is no longer needed. The
only information that gets lost is the order of the diagnostics, which
is mostly relevant for paired messages like 'inconsistent definition' +
'previous definition was here'.

tests/lint: expect complete messages in feature tests

Previously, the tests contained many comments like /* expect: 123 */,
which were useless to a casual reader since nobody is expected to learn
lint's message IDs by heart. Replace these with the complete
diagnostics, to show what lint is complaining about.

The tests named msg_*.c have been left unmodified since they mention the
full message text in their header comment.

No functional change.

lint: fix check for function calls in strict bool mode

Previously, if a function call occurred in the controlling expression,
its return type could be any scalar, not just bool. This was against
the goal of strict bool mode, which makes bool a separate and
incompabile type to all other types. For example, it would allow
controlling expressions like 'strcmp(a, b)' without the usual '!= 0',
but only if at least one of 'a' and 'b' came from a macro definition
from a system header.

The fix is that the decision of whether the type of the controlling
expression may be scalar is no longer based on the operand types but on
the main operator of the controlling expression.

lint: fix wrong error message in strict bool mode

This fix only affects the last token before a macro, as well as the last
token in the expanded macro.

tests/lint: explain the missing error message in strict bool mode

There are 2 separate bugs that lead to the missing error message.

The first bug is that when parsing a name, the information about whether
that name comes from a system header is not properly recorded for the
last token before switching from or to a system header.

The second bug is that for determining whether the type of a function
call expression is relaxed, the types of the function call arguments are
taken into account, even though the type only depends on the function
itself. The same idea applies to the operators '<<' and '>>', as their
result type only depends on the left operand, at least since C90.

tests/lint: demonstrate missing errors for strict bool mode

Seen in bin/echo/echo.c.

lint: allow initialization of struct with constant member

The operator INIT, just like RETURN and FARG, initializes an object with
an expression. The target object of such an initialization may be a
struct with constant members.

The operator ASSIGN, on the other hand, is entirely different. It
overwrites the existing value of the object, and this is not allowed for
structs that have a constant member. Therefore it was wrong to use the
operator ASSIGN for initialization.

lint: in strict bool mode, continue after error message

If a controlling expression is not of type bool but of any other scalar
type, keep the expression. Its value is still useful for control flow
analysis.

This prevents an assertion failure when running lint on the generated
scan.c, which contains a "while (1)" that does not stem from a system
header. If it did, lint would accept it, see tn_from_system_header. But
"scan.c" is not considered a system header. Maybe lint's definition of
a system header needs to be revisited.

After fixing this, there is another assertion failure though, so scan.c
is not yet ready to be inspected by lint.

lint: no special check for unary operators in strict bool mode

All interesting constellations regarding unary operators are already
covered by the simple model from ops.def.

No functional change.

lint: quote placeholders in messages for unused variables

lint: reword message about constant argument to '!'

In the other messages, operators are typically written in their literal
form as well. Using single quotes disambiguates them from normal
punctuation.

lint: prefix error messages with 'error:'

This makes it easier to find these errors in the build logs.

lint: fix reachability computation in if statements

Previously, only loop statements were considered for reachability. This
ignored the possibility of an early return in an if statement, or
unreachable branches.

tests/lint: sync redundant documentation in test for strict bool mode

lint: in strict bool mode, check initialization as well

C99 6.7.8p11 says for initialization that "the same type constraints and
conversions as for simple assignments apply", so actually apply them.
(I had just forgotten this "operator" when I first implemented strict
bool mode.)

lint: do not warn about 'do { ... } while (false)' in strict bool mode

lint: add test for 'do { ... } while (false)' in strict bool mode

Right now, this variant of the popular macro pattern is flagged as
needing a /*CONSTCOND*/ annotation. As with 'do { ... } while (0)',
there is nothing wrong with this pattern, therefore there should be no
warning.

lint: enable heuristics in test for strict bool mode

This is a preparation for allowing 'do { ... } while (false)', in
addition to the commonly used 'do { ... } while (0)', without declaring
the controlling expression /*CONSTCOND*/.

lint: add test for using a bool as array index in strict bool mode

lint: add more tests for system headers in strict bool mode

lint: add test for macro from system header in strict bool mode

Seen in usr.bin/make/meta.c:1670: FD_ZERO(&readfds). These macros
cannot be fixed since system headers must not include <stdbool.h>.
Therefore INT constants should be accepted as controlling expressions as
well.

lint: in strict bool mode, don't treat bool as arithmetic type

lint: explain failing test case in strict bool mode

lint: demonstrate wrong error message in strict bool mode

lint: simplify typeok_strict_bool_compatible

lint: add missing warning for bool() == int

lint: in strict bool mode, integer constants do not have type bool

Previously, lint1 allowed integer constants such as 0 and 1 to be used
as bool constants. This was only half-baked since after fixing all
error messages from that strict mode, there may still be integer
literals in the code that should be replaced with true or false. This
would stop a migration from int to bool in the middle, leaving
inconsistent code around.

To find the remaining type inconsistencies, treat integers and bool as
completely incompatible, even for compile time constants.

lint: prepare to make strict bool mode even stricter

Currently, strict bool mode still allows integer constant expressions to
be converted implicitly to bool. This is something that other languages
such as Go, Java, C#, Pascal don't allow.

By providing a custom implementation of <stdbool.h> that defines false
and true to custom bool constant identifiers, lint will cover these
cases as well.

To prepare for this, reword the rules and restructure the tests in
d_c99_bool_strict.c.

lint: add test for bool bit fields as operands of '|'

lint: in strict bool mode, allow bool as operands of the comma operator

lint: demonstrate wrong message for comma operator

lint: add new check for strict bool mode

In strict bool mode, bool is considered incompatible with all other
scalar types, just as in Java, C#, Pascal.

The controlling expressions in if statements, while loops, for loops and
the '?:' operator must be of type bool. The logical operators work on
bool instead of int, the bitwise operators accept both integer and bool.
The arithmetic operators don't accept bool.

Since <stdbool.h> implements bool using C preprocessor macros instead of
predefining the identifiers "true" and "false", the integer constants 0
and 1 may be used in all contexts that require a bool expression.
Except from these, no implicit conversion between bool and scalar types
is allowed.

See usr.bin/tests/xlint/lint1/d_c99_bool_strict.c for more details.

The command line option -T has been chosen because all obvious choices
(-b or -B for bool, -s or -S for strict) are already in use. The -T may
stand for "types are checked strictly".

The default behavior of lint doesn't change. The strict bool check is
purely optional.

An example program for strict bool mode is usr.bin/make, which has been
using explicit comparisons such as p != NULL, ch != '\0' or n > 0 in
most places for a long time now, even before the refactoring in 2020.

lint: extend test for strict _Bool handling

There is no danger in allowing (flags & FLAG) as a controlling
expression, provided that it is immediately compared to zero, such as in
an if statement or as the operand of a logical operator.

lint: add test for treating _Bool as non-scalar type

This strict mode is not yet implemented. The plan is to use it for
usr.bin/make, to get rid of the many possible variants of defining the
Boolean type in make.h. These variants did find some bugs, but not
reliably so. Using static analysis seems more promising for this.

In an early stage of developing this test, lint1 crashed in the enum
definition in line 213, where the node for the '?:' had been NULL. This
can happen in other situations as well, such as with syntax errors, but
these should be rare, as lint is usually only run if the compiler has
accepted the source code. Still, there should not be any assertion
failures while running lint1.

lint: remove now-unnecessary CONSTCOND comments

tests/lint: clean up

lint: add more details to 'statement not reached' message

In lib/libcompat/regexp/regexp.c, the FAIL macro expands to a compound
statement containing a function call statement and a return statement,
and the macro invocation is followed by a semicolon, forming an extra
empty statement. Which of these statements is unreachable now becomes
clear from the diagnostic, without having to inspect the preprocessed
source code.

branches: 1.24.2;
lint: in strict bool mode, allow do-while-0

Even though 0 is not a boolean constant, allow this common idiom, to
help in those cases where the C preprocessor used by lint does not mark
tokens as coming from system headers (Clang).

tests/lint: clean up tests for strict bool mode

lint: since C99, a non-void function must return a value

lint: distinguish between arguments and parameters

lint: remove redundant '#' after 'argument' in diagnostics

lint: warn about extern declarations outside headers

https://mail-index.netbsd.org/tech-userlevel/2023/03/15/msg013727.html

lint: add quotes around placeholders for the remaining messages

Reword some of the messages slightly, exchanging brevity for clarity.

Message 138 is kept as-is, as it is not yet covered by any tests.

Message 240 is kep as-is, as it is unreachable.

lint: add quotes around placeholders in 4 messages

tests/lint: demonstrate wrong syshdr check in strict bool mode

tests/lint: sync comment with reality

lint: in strict bool mode, check function arguments more strictly

When a system header defined the constant FALSE = 0, that constant could
be passed as a bool argument. On the other hand, the constant TRUE = 1
could not be passed in the same way. Remove this inconsistency.

tests/lint: extend tests for type mismatch in strict bool mode

Seen in games/gomoku when calling curses functions.

lint: fix wrong error in strict bool mode in condition with comma

For the result of the comma operator, it doesn't matter whether the
comma itself comes from a system header or not. Instead, it's the main
operator of the right operand.

Since 2021-11-16.

lint: clean up lex.c

Rename 'struct kwtab' to 'struct keyword' since a single keyword is not
a whole keyword table.

Sync comment for lex_name with reality: sbuf_t no longer contains the
hash value.

Remove redundant tests for EOF, as EOF is neither a space nor a digit
nor an xdigit.

No functional change.

tests/lint: remove false assumptions from comments

https://stackoverflow.com/q/65868752

tests/lint: one comment per expected diagnostic

This makes it possible to check for diagnostics that contain commas.

lint: improve introduction of test d_c99_bool_strict_syshdr

lint: explain why !finite(x) is not allowed in strict bool mode

lint: apply strict bool mode to lex.c

There are 2 remaining expressions:

In line 244, !(kw->kw_deco & deco) is a bitwise and. This is already
allowed for enums, it needs to be allowed for arbitrary integer
expressions as well. This covers the many places where plain integers
are used for bit fields, together with #define. This pattern is not as
typesafe as using enums, still it is common practice.

In line 769, the expression !finite(f) is a legitimate use of a function
that has return type int for traditional reasons. It's the same as for
ferror.

There are several other functions like unlink, open or strcmp that have
return type int as well, but with a different meaning. It is not yet
clear what the best way is to handle these different meanings. Having
to write finite(f) == 0 in strict bool mode doesn't look idiomatic, on
the other hand, !strcmp(s1, s2) is exactly the pattern that strict bool
mode wants to avoid.

lint: fix error message for relaxed bool operations in system headers

In strict mode, allowing 1 as bool constant expression is probably not
needed in practice since most comparisons are != 0 instead of == 0.

Furthermore, in the expression (flags & 0x0002) == true, comparing with
true is misleading since the '==' operator can never evaluate to true in
this case.

lint: fix two wrong error messages in strict bool mode

The strict bool mode gets complicated because for system headers the
rules need to be relaxed since they cannot be changed easily, often not at all.

Still, if lint validates a program in strict bool mode, that program
must run with equal behavior regarding boolean expressions even on a
pre-C99 platform.

lint: extend test for strict bool mode and system headers

lint: allow system headers to use int as bool, even in strict bool mode

lint: add more tests for system headers in strict bool mode

tests/lint: remove .exp files, as they have become redundant

Now that each lint1 test lists all generated diagnostics as 'expect'
comments, the information from the .exp files is no longer needed. The
only information that gets lost is the order of the diagnostics, which
is mostly relevant for paired messages like 'inconsistent definition' +
'previous definition was here'.

tests/lint: demonstrate wrong syshdr check in strict bool mode

lint: in strict bool mode, check function arguments more strictly

When a system header defined the constant FALSE = 0, that constant could
be passed as a bool argument. On the other hand, the constant TRUE = 1
could not be passed in the same way. Remove this inconsistency.

tests/lint: extend tests for type mismatch in strict bool mode

Seen in games/gomoku when calling curses functions.

lint: fix wrong error in strict bool mode in condition with comma

For the result of the comma operator, it doesn't matter whether the
comma itself comes from a system header or not. Instead, it's the main
operator of the right operand.

Since 2021-11-16.

lint: clean up lex.c

Rename 'struct kwtab' to 'struct keyword' since a single keyword is not
a whole keyword table.

Sync comment for lex_name with reality: sbuf_t no longer contains the
hash value.

Remove redundant tests for EOF, as EOF is neither a space nor a digit
nor an xdigit.

No functional change.

tests/lint: remove false assumptions from comments

https://stackoverflow.com/q/65868752

lint: allow initialization of struct with constant member

The operator INIT, just like RETURN and FARG, initializes an object with
an expression. The target object of such an initialization may be a
struct with constant members.

The operator ASSIGN, on the other hand, is entirely different. It
overwrites the existing value of the object, and this is not allowed for
structs that have a constant member. Therefore it was wrong to use the
operator ASSIGN for initialization.

lint: add quotes around placeholder in message 214

function '%s' expects to return value

lint: prefix error messages with 'error:'

This makes it easier to find these errors in the build logs.

lint: improve introduction of test d_c99_bool_strict_syshdr

lint: explain why !finite(x) is not allowed in strict bool mode

lint: apply strict bool mode to lex.c

There are 2 remaining expressions:

In line 244, !(kw->kw_deco & deco) is a bitwise and. This is already
allowed for enums, it needs to be allowed for arbitrary integer
expressions as well. This covers the many places where plain integers
are used for bit fields, together with #define. This pattern is not as
typesafe as using enums, still it is common practice.

In line 769, the expression !finite(f) is a legitimate use of a function
that has return type int for traditional reasons. It's the same as for
ferror.

There are several other functions like unlink, open or strcmp that have
return type int as well, but with a different meaning. It is not yet
clear what the best way is to handle these different meanings. Having
to write finite(f) == 0 in strict bool mode doesn't look idiomatic, on
the other hand, !strcmp(s1, s2) is exactly the pattern that strict bool
mode wants to avoid.

lint: fix error message for relaxed bool operations in system headers

In strict mode, allowing 1 as bool constant expression is probably not
needed in practice since most comparisons are != 0 instead of == 0.

Furthermore, in the expression (flags & 0x0002) == true, comparing with
true is misleading since the '==' operator can never evaluate to true in
this case.

lint: fix two wrong error messages in strict bool mode

The strict bool mode gets complicated because for system headers the
rules need to be relaxed since they cannot be changed easily, often not at all.

Still, if lint validates a program in strict bool mode, that program
must run with equal behavior regarding boolean expressions even on a
pre-C99 platform.

lint: extend test for strict bool mode and system headers

lint: allow system headers to use int as bool, even in strict bool mode

lint: add more tests for system headers in strict bool mode

lint: warn about extern declarations outside headers

https://mail-index.netbsd.org/tech-userlevel/2023/03/15/msg013727.html

lint: add common header for all tests

For those tests that didn't use GCC-style line markers such as "# 2",
the line numbers of the diagnostics stay the same. This is purely
conincidental. Before, the 3 lines came from lint's built-in
definitions (see 'builtins' in main1.c), and line number counting
continued as if nothing had happened, making the first line of the
actual file line 4. These 3 built-in lines are now replaced with 3
lines of file header.

branches: 1.1.2;
Deprecate tests/util.

lint: warn about extern declarations outside headers

https://mail-index.netbsd.org/tech-userlevel/2023/03/15/msg013727.html

tests/lint: clean up

The .exp files are no longer kept under version control, so there's no
reason anymore to forcefully trigger a warning or an error.

lint: add quotes around placeholders for the remaining messages

Reword some of the messages slightly, exchanging brevity for clarity.

Message 138 is kept as-is, as it is not yet covered by any tests.

Message 240 is kep as-is, as it is unreachable.

lint: add quotes around placeholders in 4 messages

tests/lint: expect complete messages in feature tests

Previously, the tests contained many comments like /* expect: 123 */,
which were useless to a casual reader since nobody is expected to learn
lint's message IDs by heart. Replace these with the complete
diagnostics, to show what lint is complaining about.

The tests named msg_*.c have been left unmodified since they mention the
full message text in their header comment.

No functional change.

tests/lint: test precedence of __real__ and cast_expression

lint: fix wrong warning about uninitialized _Complex variable

Seen in divxc3.c.

tests/lint: demonstrate wrong lint warning about complex variables

tests/lint: move description of tests into the tests themselves

In most cases the descriptions didn't add much to the test name anyway.

lint: format tests in a common style

The lint tests do not focus on the whitespace since that is the most
boring part of code style. Therefore, format the tests to be readable
by following share/misc/style as close as possible.

lint: add common header for all tests

For those tests that didn't use GCC-style line markers such as "# 2",
the line numbers of the diagnostics stay the same. This is purely
conincidental. Before, the 3 lines came from lint's built-in
definitions (see 'builtins' in main1.c), and line number counting
continued as if nothing had happened, making the first line of the
actual file line 4. These 3 built-in lines are now replaced with 3
lines of file header.

branches: 1.2.2; 1.2.4; 1.2.8;
use a different function instead of __builtin_isnan, because it is polymorphic
and we don't handle this yet.

add more tests

tests/lint: remove .exp files, as they have become redundant

Now that each lint1 test lists all generated diagnostics as 'expect'
comments, the information from the .exp files is no longer needed. The
only information that gets lost is the order of the diagnostics, which
is mostly relevant for paired messages like 'inconsistent definition' +
'previous definition was here'.

tests/lint: expect complete messages in feature tests

Previously, the tests contained many comments like /* expect: 123 */,
which were useless to a casual reader since nobody is expected to learn
lint's message IDs by heart. Replace these with the complete
diagnostics, to show what lint is complaining about.

The tests named msg_*.c have been left unmodified since they mention the
full message text in their header comment.

No functional change.

lint: fix wrong warning about uninitialized _Complex variable

Seen in divxc3.c.

tests/lint: demonstrate wrong lint warning about complex variables

lint: warn about function definitions without header declaration

The existing warning was only issued for function declarations, not for
function definitions.

The interesting change in the tests is in msg_351.c. Many other tests
use non-static functions due to their syntactic brevity. In these
tests, the warning is disabled individually, to allow new functions to
be added without generating warning 351.

lint: join grammar rules for initialization

The '%prec T_COMMA' is necessary to avoid lots of parse errors in the
lint1 unit tests. Curiously, further down in the grammar, for compound
literals, the '%prec T_COMMA' is not necessary, even though the context
looks very similar.

No functional change.

lint: add common header for all tests

For those tests that didn't use GCC-style line markers such as "# 2",
the line numbers of the diagnostics stay the same. This is purely
conincidental. Before, the 3 lines came from lint's built-in
definitions (see 'builtins' in main1.c), and line number counting
continued as if nothing had happened, making the first line of the
actual file line 4. These 3 built-in lines are now replaced with 3
lines of file header.

one t in literal.

one t in literal.

add one more test

lint: distinguish between arguments and parameters

lint: warn about function definitions without header declaration

The existing warning was only issued for function declarations, not for
function definitions.

The interesting change in the tests is in msg_351.c. Many other tests
use non-static functions due to their syntactic brevity. In these
tests, the warning is disabled individually, to allow new functions to
be added without generating warning 351.

tests/lint: merge tests for declaration after statement

tests/lint: document where some C99 tests come from

These tests were added due to PR#45417.

lint: format tests in a common style

The lint tests do not focus on the whitespace since that is the most
boring part of code style. Therefore, format the tests to be readable
by following share/misc/style as close as possible.

lint: add common header for all tests

For those tests that didn't use GCC-style line markers such as "# 2",
the line numbers of the diagnostics stay the same. This is purely
conincidental. Before, the 3 lines came from lint's built-in
definitions (see 'builtins' in main1.c), and line number counting
continued as if nothing had happened, making the first line of the
actual file line 4. These 3 built-in lines are now replaced with 3
lines of file header.

branches: 1.1.2;
Deprecate tests/util.

tests/lint: merge tests for declaration after statement

tests/lint: document where some C99 tests come from

These tests were added due to PR#45417.

lint: format tests in a common style

The lint tests do not focus on the whitespace since that is the most
boring part of code style. Therefore, format the tests to be readable
by following share/misc/style as close as possible.

lint: add common header for all tests

For those tests that didn't use GCC-style line markers such as "# 2",
the line numbers of the diagnostics stay the same. This is purely
conincidental. Before, the 3 lines came from lint's built-in
definitions (see 'builtins' in main1.c), and line number counting
continued as if nothing had happened, making the first line of the
actual file line 4. These 3 built-in lines are now replaced with 3
lines of file header.

branches: 1.1.2;
Deprecate tests/util.

tests/lint: merge tests for declaration after statement

tests/lint: document where some C99 tests come from

These tests were added due to PR#45417.

lint: format tests in a common style

The lint tests do not focus on the whitespace since that is the most
boring part of code style. Therefore, format the tests to be readable
by following share/misc/style as close as possible.

lint: add common header for all tests

For those tests that didn't use GCC-style line markers such as "# 2",
the line numbers of the diagnostics stay the same. This is purely
conincidental. Before, the 3 lines came from lint's built-in
definitions (see 'builtins' in main1.c), and line number counting
continued as if nothing had happened, making the first line of the
actual file line 4. These 3 built-in lines are now replaced with 3
lines of file header.

branches: 1.1.4; 1.1.8;
Handle another declaration after statement case for lint in c99 mode.
Add the corresponding testcase.

lint: warn about extern declarations outside headers

https://mail-index.netbsd.org/tech-userlevel/2023/03/15/msg013727.html

lint: add common header for all tests

For those tests that didn't use GCC-style line markers such as "# 2",
the line numbers of the diagnostics stay the same. This is purely
conincidental. Before, the 3 lines came from lint's built-in
definitions (see 'builtins' in main1.c), and line number counting
continued as if nothing had happened, making the first line of the
actual file line 4. These 3 built-in lines are now replaced with 3
lines of file header.

test for c99 flexible packed arrays

tests/lint: reorganize tests

Tests for a single working language construct don't usually need a
separate file, they can be grouped together, like in expr.c or gcc.c.

lint: warn about extern declarations outside headers

https://mail-index.netbsd.org/tech-userlevel/2023/03/15/msg013727.html

lint: add common header for all tests

For those tests that didn't use GCC-style line markers such as "# 2",
the line numbers of the diagnostics stay the same. This is purely
conincidental. Before, the 3 lines came from lint's built-in
definitions (see 'builtins' in main1.c), and line number counting
continued as if nothing had happened, making the first line of the
actual file line 4. These 3 built-in lines are now replaced with 3
lines of file header.

add a test for the bug I fixed yesterday, and explain the tests.

branches: 1.1.2;
Deprecate tests/util.

tests/lint: group tests by topic

lint: fix crash for invalid __func__ (since 2023-01-29)

lint: warn about extern declarations outside headers

https://mail-index.netbsd.org/tech-userlevel/2023/03/15/msg013727.html

lint: fix definition of __func__

lint: demonstrate wrong declaration of __func__

lint: format tests in a common style

The lint tests do not focus on the whitespace since that is the most
boring part of code style. Therefore, format the tests to be readable
by following share/misc/style as close as possible.

lint: add common header for all tests

For those tests that didn't use GCC-style line markers such as "# 2",
the line numbers of the diagnostics stay the same. This is purely
conincidental. Before, the 3 lines came from lint's built-in
definitions (see 'builtins' in main1.c), and line number counting
continued as if nothing had happened, making the first line of the
actual file line 4. These 3 built-in lines are now replaced with 3
lines of file header.

branches: 1.1.2;
Deprecate tests/util.

tests/lint: group tests by topic

lint: add details to message about too many initializers

lint: reword messages about array subscripts to sound more natural

tests/lint: sort multiple diagnostics per line chronologically

For now, the chronologic order is not enforced but has to be established
manually, for example by removing all 'expect' comment lines and
regenerating them with 'accept.sh -u'.

While here, clean up a few instances that came up when regenerating the
'expect' comments, such as wrong indentation or needless deviation from
the 'expect+1' form.

lint: clean up the wording of a few diagnostics

lint: warn about extern declarations outside headers

https://mail-index.netbsd.org/tech-userlevel/2023/03/15/msg013727.html

tests/lint: merge tests for initialization

tests/lint: remove redundant tests

The names of the tests were misleading: 'recursive' should have been
'nested', and the interesting topic in the 'cast' tests was not the cast
but the pointer dereference.

lint: add quotes around placeholders for the remaining messages

Reword some of the messages slightly, exchanging brevity for clarity.

Message 138 is kept as-is, as it is not yet covered by any tests.

Message 240 is kep as-is, as it is unreachable.

tests/lint: make 'expect+-' comments stricter

Previously, the expectations from these comments were already satisfied
if the expectation occurred somewhere in the actual message from lint.
This meant that the prefix 'error:' or 'warning:' could be omitted from
the 'expect' comment. These omissions were hard to see in a manual
review. Now any omissions must be visually marked with '...'.

The test msg_342 now reports its messages properly as being in the file
msg_342.c, rather than msg_341.c. This had been a copy-and-paste
mistake.

tests/lint: expect complete messages in feature tests

Previously, the tests contained many comments like /* expect: 123 */,
which were useless to a casual reader since nobody is expected to learn
lint's message IDs by heart. Replace these with the complete
diagnostics, to show what lint is complaining about.

The tests named msg_*.c have been left unmodified since they mention the
full message text in their header comment.

No functional change.

tests/lint: extend documentation for omitted braces in initializer

lint: remove spaces around bit-field colon

As seen in /usr/share/misc/style.

No binary change.

tests/lint: improve test for initialization of array of unknown size

Previously, the test didn't show that the size of the resulting object
was updated too early.

lint: fix handling of initializations

The implementation from March 2021 added proper support for designators
but didn't model the brace levels correctly. In particular, it could
not handle additional braces or omitted braces. In such a case, lint
skipped the remaining initializers from the initialization. Due to
this, type errors in the remaining initializers went unnoticed. Another
effect was that arrays of unknown size were wrongly reported as having
size 0.

Both GCC and Clang recommend placing braces around each sub-type that is
initialized, such as a struct, union or array. Postfix does not follow
these recommendations, therefore lint had to be disabled in
external/ibm-public/postfix/Makefile.inc. This commit fixes the bugs
mentioned there.

lint: make function names a bit more concise

No binary change.

tests/lint: add more examples for initialization, from C99

lint: fix initialization with brace-enclosed string literal

C99 allows this form in 6.7.8p14 and p15.

The previous lint tests did not cover the case of an array at the top
level of the object to be initialized, they only covered the error cases
(d_c99_init.c, variables 'prefixed_message' and 'message_with_suffix').

Lint is now more generous than strictly required by C99, but since GCC
and Clang already cover the case of 'message_with_suffix', this is ok.

The test d_init_array_using_string.c was wrong before in rejecting the
initializer for 'extra_braces'. I had tested that Clang generated a
warning for this, but I had not inspected its warning carefully enough.
Clang had not warned about the extra braces but only about a type
mismatch since I tested on a platform where wchar_t was 16 bit.

tests/lint: demonstrate wrong warning when initializing a string

lint: add parentheses after sizeof, as required by share/misc/style

No functional change.

lint: do not error out of a struct is initialized without braces

This allows to process lib/libc/gen/sysctl.c 1.38 from 2021-03-30, as
well as its precedessor 1.37, which had a workaround just for lint.

While unusual, C99 allows these.

tests/lint: test 'scalar type cannot use designator'

tests/lint: remove unnecessary empty lines from test

In a separate commit to not cause an unnecessarily large diff in the
previous commit.

lint: add error about out-of-bounds array subscripts

This check is not strictly necessary since any C99 compiler must
diagnose them as well, it is rather meant for demonstrating how to do
the check in lint, and for symmetry with the 'unknown member' error
message. These provide insight into how the data structures in init.c
are meant to be accessed.

lint: add type information for message about unknown member name