It's enough to have modtab, which describes the properties of the
various operators. There is no need to have a second table imods that
holds the same content. Rather make modtab constant as well.
The only possible functional change is that the names of the internal
operators 'no-op', '++', '--', 'real', 'imag' and 'case' may appear in
diagnostics, where previously lint invoked undefined behavior by passing
a null pointer for a '%s' conversion specifier.
The abbreviations in the table of operator properties had been wrong
since ops.def 1.10 from 2021-01-12, when strict bool mode was added. In
an earlier working draft, I had named that column 'takes_others' instead
of 'requires_bool', that's where the 'o' came from.
The names of the macro arguments had been wrong since op.h 1.11 from
2021-01-09, when the order of the columns changed and the macros were
not adjusted accordingly. Since all the properties of the operator
table are uniform, this didn't result in any bugs, it was just confusing
for human readers.
Clang-tidy suggests to enclose the macro arguments in oper.c in
parentheses but that is not possible since the arguments are either
empty or 1, and the syntactical ambiguity of the '+ 0' being either a
unary or a binary operator is needed here.
No change to the resulting binary.
Since today, lint's strict bool mode requires initializers to have the
correct type. The flags in kwtab are of type bool and were initialized
with an int, for brevity. Keep the brevity and do the conversion from
int to bool in a macro.
By defining several macros for the different kinds of keywords, reduce
the clutter of having 2 additional zeroes per line. The macros also
remove the redundancy and thereby the possible inconsistency of filling
the wrong fields since these depend on the token type.
No functional change. The only change to the binary is due to the
changed line numbers in the calls to lint_assert.
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.)
Even though clear_warning_flags and its companions are implemented as
macros, they act like ordinary functions. Do not distract the reader by
using uppercase names for them.
No functional change.
The new code may not be the most beautiful, but it fixes all bugs that
occurred while testing message 327. The grammar rules are taken from
C99 6.8.2, so it's no surprise they work well.
The code in the C grammar is generated by yacc and is not checked by
lint's strict bool mode, therefore the replacement was done manually.
No change to the resulting change.
My previous commit message was wrong in saying that the '%prec' was
necessary. It is not necessary.
Most probably I misspelled the name of the grammar rule as opt_comma
instead of comma_opt, which would lead to the same number of conflicts
in the grammar plus a warning, but no build failure.
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.
Previously, the grammar syntactically accepted the following code:
int var = .member = 12345;
The designation '.member =' can only be used with brace-enclosed
initializers.
In d_c99_init.c, the initialization of array_with_designator failed.
The designator '.member' from that initialization was not cleaned up
before starting the next initialization.
These two functions are supposed to model the designator that is used
for initializing structs and arrays. The implementation is still buggy
and does not work at all for C99 designators with multiple names, see
d_init_pop_member.c.
For now, just rename the functions to head in the right direction.
No functional change.
The operator NAME has the name 'name', therefore no special case is
needed.
Having the words 'with type' in the message makes the message easier to
find from the debug log. Given that the operator name is used unquoted,
the log message 'name: int value=111' was nearly impossible to find in
the code.
Replace the '()' with an actual word, to avoid any confusion about
whether the type name might be a function type without prototype.
Reduce the amount of '=' signs, instead use commas to separate the
properties of the node.
No functional change outside debug mode.
The previous name could be too easily confused with the type qualifier
'const'. The operator name is mainly used in the debug log, only
occasionally in the output. Since 'constant' is not a "real" operator,
it probably doesn't occur in messages at all.
The debugging code is needed by the soon-to-be-added proper handling of
array subscript initializers such as '.member[123].member = 12345'.
No functional change.
