![[BACK]](/icons/back.gif){kind=icon}
Up to [cvs.NetBSD.org] / src / tests / usr.bin / xlint
Request diff between arbitrary revisions
Keyword substitution: kv
Default branch: MAIN
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.