Up to [cvs.NetBSD.org] / src / tests / usr.bin / xlint / lint1
Request diff between arbitrary revisions
Default branch: MAIN
Revision 1.34, Fri Jun 17 20:23:58 2022 UTC (21 months, 1 week ago) by rillig
Branch: MAIN
CVS Tags: HEAD
Changes since 1.33: +0 -0
lines
FILE REMOVED
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'.
Revision 1.33 / (download) - annotate - [select for diffs], Sat Jan 15 14:22:03 2022 UTC (2 years, 2 months ago) by rillig
Branch: MAIN
Changes since 1.32: +172 -172
lines
Diff to previous 1.32 (colored)
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.
Revision 1.32 / (download) - annotate - [selected], Tue Nov 16 21:01:06 2021 UTC (2 years, 4 months ago) by rillig
Branch: MAIN
Changes since 1.31: +4 -0
lines
Diff to previous 1.31 (colored)
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.
Revision 1.31 / (download) - annotate - [select for diffs], Tue Nov 16 18:27:04 2021 UTC (2 years, 4 months ago) by rillig
Branch: MAIN
Changes since 1.30: +0 -2
lines
Diff to previous 1.30 (colored) to selected 1.32 (colored)
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.
Revision 1.30 / (download) - annotate - [select for diffs], Tue Nov 16 06:55:03 2021 UTC (2 years, 4 months ago) by rillig
Branch: MAIN
Changes since 1.29: +6 -5
lines
Diff to previous 1.29 (colored) to selected 1.32 (colored)
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.
Revision 1.29 / (download) - annotate - [select for diffs], Sun Nov 14 11:23:52 2021 UTC (2 years, 4 months ago) by rillig
Branch: MAIN
Changes since 1.28: +5 -0
lines
Diff to previous 1.28 (colored) to selected 1.32 (colored)
tests/lint: demonstrate missing errors for strict bool mode Seen in bin/echo/echo.c.
Revision 1.28 / (download) - annotate - [select for diffs], Sat Aug 14 12:46:24 2021 UTC (2 years, 7 months ago) by rillig
Branch: MAIN
Changes since 1.27: +4 -4
lines
Diff to previous 1.27 (colored) to selected 1.32 (colored)
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.
Revision 1.27 / (download) - annotate - [select for diffs], Sun Jul 4 07:09:39 2021 UTC (2 years, 8 months ago) by rillig
Branch: MAIN
Changes since 1.26: +1 -0
lines
Diff to previous 1.26 (colored) to selected 1.32 (colored)
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.
Revision 1.26 / (download) - annotate - [select for diffs], Fri Jul 2 18:52:20 2021 UTC (2 years, 8 months ago) by rillig
Branch: MAIN
Changes since 1.25: +92 -92
lines
Diff to previous 1.25 (colored) to selected 1.32 (colored)
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.
Revision 1.25 / (download) - annotate - [select for diffs], Fri Apr 9 20:12:00 2021 UTC (2 years, 11 months ago) by rillig
Branch: MAIN
CVS Tags: cjep_sun2x-base1,
cjep_sun2x-base,
cjep_sun2x,
cjep_staticlib_x-base1,
cjep_staticlib_x-base,
cjep_staticlib_x
Changes since 1.24: +3 -3
lines
Diff to previous 1.24 (colored) to selected 1.32 (colored)
lint: quote placeholders in messages for unused variables
Revision 1.24 / (download) - annotate - [select for diffs], Fri Apr 2 22:41:54 2021 UTC (2 years, 11 months ago) by rillig
Branch: MAIN
Changes since 1.23: +2 -2
lines
Diff to previous 1.23 (colored) to selected 1.32 (colored)
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.
Revision 1.23 / (download) - annotate - [select for diffs], Sun Mar 21 20:44:59 2021 UTC (3 years ago) by rillig
Branch: MAIN
Changes since 1.22: +146 -146
lines
Diff to previous 1.22 (colored) to selected 1.32 (colored)
lint: prefix error messages with 'error:' This makes it easier to find these errors in the build logs.
Revision 1.22 / (download) - annotate - [select for diffs], Sun Mar 21 14:36:59 2021 UTC (3 years ago) by rillig
Branch: MAIN
Changes since 1.21: +1 -0
lines
Diff to previous 1.21 (colored) to selected 1.32 (colored)
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.
Revision 1.21 / (download) - annotate - [select for diffs], Sun Mar 21 14:12:46 2021 UTC (3 years ago) by rillig
Branch: MAIN
Changes since 1.20: +147 -147
lines
Diff to previous 1.20 (colored) to selected 1.32 (colored)
tests/lint: sync redundant documentation in test for strict bool mode
Revision 1.20 / (download) - annotate - [select for diffs], Sat Mar 20 17:18:50 2021 UTC (3 years ago) by rillig
Branch: MAIN
Changes since 1.19: +2 -0
lines
Diff to previous 1.19 (colored) to selected 1.32 (colored)
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.)
Revision 1.19 / (download) - annotate - [select for diffs], Sat Feb 20 18:55:10 2021 UTC (3 years, 1 month ago) by rillig
Branch: MAIN
Changes since 1.18: +0 -1
lines
Diff to previous 1.18 (colored) to selected 1.32 (colored)
lint: do not warn about 'do { ... } while (false)' in strict bool mode
Revision 1.18 / (download) - annotate - [select for diffs], Sat Feb 20 18:52:58 2021 UTC (3 years, 1 month ago) by rillig
Branch: MAIN
Changes since 1.17: +2 -0
lines
Diff to previous 1.17 (colored) to selected 1.32 (colored)
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.
Revision 1.17 / (download) - annotate - [select for diffs], Sat Feb 20 18:49:26 2021 UTC (3 years, 1 month ago) by rillig
Branch: MAIN
Changes since 1.16: +15 -0
lines
Diff to previous 1.16 (colored) to selected 1.32 (colored)
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*/.
Revision 1.16 / (download) - annotate - [select for diffs], Sat Feb 20 18:02:58 2021 UTC (3 years, 1 month ago) by rillig
Branch: MAIN
Changes since 1.15: +1 -0
lines
Diff to previous 1.15 (colored) to selected 1.32 (colored)
lint: add test for using a bool as array index in strict bool mode
Revision 1.15 / (download) - annotate - [select for diffs], Sun Jan 17 23:00:41 2021 UTC (3 years, 2 months ago) by rillig
Branch: MAIN
Changes since 1.14: +0 -3
lines
Diff to previous 1.14 (colored) to selected 1.32 (colored)
lint: add more tests for system headers in strict bool mode
Revision 1.14 / (download) - annotate - [select for diffs], Sun Jan 17 21:19:06 2021 UTC (3 years, 2 months ago) by rillig
Branch: MAIN
Changes since 1.13: +3 -0
lines
Diff to previous 1.13 (colored) to selected 1.32 (colored)
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.
Revision 1.13 / (download) - annotate - [select for diffs], Sun Jan 17 13:50:33 2021 UTC (3 years, 2 months ago) by rillig
Branch: MAIN
Changes since 1.12: +5 -2
lines
Diff to previous 1.12 (colored) to selected 1.32 (colored)
lint: in strict bool mode, don't treat bool as arithmetic type
Revision 1.12 / (download) - annotate - [select for diffs], Sun Jan 17 13:15:03 2021 UTC (3 years, 2 months ago) by rillig
Branch: MAIN
Changes since 1.11: +1 -1
lines
Diff to previous 1.11 (colored) to selected 1.32 (colored)
lint: explain failing test case in strict bool mode
Revision 1.11 / (download) - annotate - [select for diffs], Sun Jan 17 11:32:06 2021 UTC (3 years, 2 months ago) by rillig
Branch: MAIN
Changes since 1.10: +1 -0
lines
Diff to previous 1.10 (colored) to selected 1.32 (colored)
lint: demonstrate wrong error message in strict bool mode
Revision 1.10 / (download) - annotate - [select for diffs], Sat Jan 16 18:58:21 2021 UTC (3 years, 2 months ago) by rillig
Branch: MAIN
Changes since 1.9: +1 -1
lines
Diff to previous 1.9 (colored) to selected 1.32 (colored)
lint: simplify typeok_strict_bool_compatible
Revision 1.9 / (download) - annotate - [select for diffs], Sat Jan 16 18:48:52 2021 UTC (3 years, 2 months ago) by rillig
Branch: MAIN
Changes since 1.8: +1 -0
lines
Diff to previous 1.8 (colored) to selected 1.32 (colored)
lint: add missing warning for bool() == int
Revision 1.8 / (download) - annotate - [select for diffs], Sat Jan 16 16:03:47 2021 UTC (3 years, 2 months ago) by rillig
Branch: MAIN
Changes since 1.7: +28 -2
lines
Diff to previous 1.7 (colored) to selected 1.32 (colored)
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.
Revision 1.7 / (download) - annotate - [select for diffs], Sat Jan 16 15:02:11 2021 UTC (3 years, 2 months ago) by rillig
Branch: MAIN
Changes since 1.6: +117 -104
lines
Diff to previous 1.6 (colored) to selected 1.32 (colored)
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.
Revision 1.6 / (download) - annotate - [select for diffs], Fri Jan 15 23:15:28 2021 UTC (3 years, 2 months ago) by rillig
Branch: MAIN
Changes since 1.5: +1 -0
lines
Diff to previous 1.5 (colored) to selected 1.32 (colored)
lint: add test for bool bit fields as operands of '|'
Revision 1.5 / (download) - annotate - [select for diffs], Fri Jan 15 22:07:54 2021 UTC (3 years, 2 months ago) by rillig
Branch: MAIN
Changes since 1.4: +0 -2
lines
Diff to previous 1.4 (colored) to selected 1.32 (colored)
lint: in strict bool mode, allow bool as operands of the comma operator
Revision 1.4 / (download) - annotate - [select for diffs], Fri Jan 15 22:04:27 2021 UTC (3 years, 2 months ago) by rillig
Branch: MAIN
Changes since 1.3: +2 -0
lines
Diff to previous 1.3 (colored) to selected 1.32 (colored)
lint: demonstrate wrong message for comma operator
Revision 1.3 / (download) - annotate - [select for diffs], Tue Jan 12 20:42:01 2021 UTC (3 years, 2 months ago) by rillig
Branch: MAIN
Changes since 1.2: +103 -6
lines
Diff to previous 1.2 (colored) to selected 1.32 (colored)
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.
Revision 1.2 / (download) - annotate - [select for diffs], Mon Jan 11 00:28:28 2021 UTC (3 years, 2 months ago) by rillig
Branch: MAIN
Changes since 1.1: +6 -2
lines
Diff to previous 1.1 (colored) to selected 1.32 (colored)
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.
Revision 1.1 / (download) - annotate - [select for diffs], Sun Jan 10 17:43:46 2021 UTC (3 years, 2 months ago) by rillig
Branch: MAIN
Diff to selected 1.32 (colored)
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.