Before: error: expected undefined [99]
After: error: 'expected' undefined [99]
Seen in external/mpl/bind, which for Clang defines in stdatomic.h:
> #define atomic_exchange_explicit(obj, desired, order) \
> __c11_atomic_exchange_explicit(obj, expected, order)
Note the mismatch between 'desired' and 'expected'.
That statement may have been true in 1993, but definitely is not true
anymore, as of 2021.
The part about "needs to be completely redone" is still true though
since indent cannot even format its own source code in an acceptable
way.
The new format follows the common conventions for file locations and
allows quick navigation in IDEs.
To trigger an internal error, it suffices to have 2 tokens in lint1's
input, after preprocessing: 'void __pure'.
C99 does not define names for the head parts of the 'for' statements, it
just calls them clause-1, expression-2 and expression-3. Therefore the
rather abstract name 'expr3'.
No functional change.
The previous names were highly ambiguous. The 'decl' could have meant
'declaration', which would be the usual abbreviation. It could also be
split into 'dec' and 'l', meaning 'declaration level', which would make
more sense in this particular context.
To avoid having to guess anything about these names, rename the
functions. Instead of 'push' and 'pop', I renamed them to 'begin' and
'end' since these are the high-level operation that are of interest.
That the hierarchy of declaration levels is implemented as a stack is
nice to know but not as important to understand the whole situation.
No functional change.
This makes the code several lines longer but way more readable. In the
previous dense expression it was hard to see what was going on at all
and that there are two completely separate situations in which this
warning applies.
No functional change.
From the previous commit, there was an off-by-one error left, which was
due to the interaction between designation_add_subscript and
extend_if_array_of_unknown_size.
The other crucial point was to call initstack_pop_nobrace before
accessing the "current initialization stack element". Without this
call, in msg_168.c the "current element" would point to the initializer
level for 'const char *' instead of the one for 'array of const char *'.
One more step towards supporting C99.
Initialization is still buggy but better than before. The remaining bug
is that only the first designator determines the array size, and after
that, the array is no longer considered of unknown size. This
contradicts C99. More improvements to come.
One of the latest "refactorings" introduced a small and practically
unimportant memory leak. If the last initializer in an initialization
had a designator, that designator was not freed.
When the "current initialization" was still a global variable with
unlimited lifetime, it was freed at the beginning of the next
initialization. After the refactorings, this "next initialization"
could no longer see anything from the previous initialization since all
references have been cleaned up at that point. Freeing the memory so
late and in an almost totally unrelated place was a bad idea anyway.
There are far too many places that modify the top element of the
initializer stack. Each of these places should get its own logging, as
long as the code is still complicated. These places are now clearly
marked with initstk_lvalue.
No functional change.
This makes it possible to accurately model C99 initializers, including
their optional designators. Previously, array subscripts had not been
modeled at all.
In the previous commit, debug_designation crashed immediately since I
had not run the code in debug mode even once. The condition 'name !=
head' was a left-over from the old times where the designator was still
a circular list.
No functional change outside debug mode.
This has been a long-standing limitation of lint. Now it is almost
ready for C99, see the list of "major changes" in the foreword of C99.
One known remaining bug in the area of initialization is designators
with several levels, such as '.member[2].member.member'. Oh, and
designators for arrays are only supported in the parser but not in the
type checker. There's still some work to do.
Missing braces after 'if', since init.c 1.68 from 2021-02-20.
GCC 10 doesn't complain about this even with -Wmisleading-indentation
since at least one of the involved lines is a macro invocation (in this
case both lines). GCC 11 will warn about this.
Clang warns about this, but the regular Clang build currently fails for
other reasons, so this problem didn't show up there either.
Now that the code contains explicit markers for starting and ending an
initialization, and having the guarantee that an assertion fails
whenever some code accesses the state of the "current initialization"
even though there is no ongoing initialization gives me much more
confidence in the correctness of the code. The calls to
begin_initialization and end_initialization always appear in pairs,
enclosing the minimal amount of code necessary for initialization.
In a nutshell, global modifiable state is error-prone and hard to
understand.
A nice side effect is that the grammar no longer needs a special rule
for the outermost initializer since the functions for the debug logging
are now called explicitly.
The code that misuses the initialization state just because it needs to
temporarily store a sym_t somewhere is now clearly marked as such. A
GCC statement expression can appear anywhere and is therefore
independent of the initialization. Most probably the code can simply
refer to the local variable in the grammar rule itself, or this variable
needs to be encoded in the grammar %union. For sure there is a better
way to handle this.
There is no longer a need that the function 'declare' initializes the
initialization state, it was just the wrong place to do this.
This indirection will be needed to handle nested initializations, which
are a new feature of C99. These are currently not handled correctly,
see msg_171.c.
No functional change.
While here, reword the message, avoiding operators and parentheses.
Since 2021-01-02, providing the precise type name is as easy as the
broad type classification (just replace tspec_name with type_name), and
it's definitely more useful to the human readers.
