Nick Bowler [Sun, 10 Jul 2011 16:25:37 +0000 (12:25 -0400)]
Split up interactive/noninteractive loops.
Readline isn't well suited for non-interactive loops since it tends to
print stuff to standard output. So use two loops: a readline-based one
and a getline-based one.
Nick Bowler [Thu, 7 Jul 2011 00:39:47 +0000 (20:39 -0400)]
Don't gratuitously reject inline specifiers.
We actually do support functions now, so we need to handle inline.
Turns out the last user of the old output routines (the code that
prints "inline") didn't actually work properly, so port it over to
the new interface.
Nick Bowler [Wed, 6 Jul 2011 02:43:42 +0000 (22:43 -0400)]
Kill the "horizontal" declarator chain.
The "next" pointer in declarators is used in exactly one place: the list
of declarators of a declaration. Move this chain to the toplevel so
that we get a list of declarations instead: now every struct cdecl has
exatly one declarator.
This helps eliminate the nasty hack in "explain" to print multiple
declarators.
Nick Bowler [Mon, 4 Jul 2011 22:11:51 +0000 (18:11 -0400)]
Add support for empty declarators.
This allows the parser to recognize type names which are required for
function prototypes, as well as actual declarations. This also makes it
easy to let the user ask for an explanation of types. For instance:
Nick Bowler [Sat, 25 Jun 2011 13:45:16 +0000 (09:45 -0400)]
Add support for array declarators.
Currently there is a (I think quite reasonable) restriction that the
array length either be unspecified, a positive integer constant, an
identifier, or *.
Nick Bowler [Sat, 25 Jun 2011 12:52:17 +0000 (08:52 -0400)]
Restrict the contexts in which typedef names can appear.
This should resolve a rather nasty ambiguity in the C grammar:
[declaration] -> [declaration-specifiers] ;
-> [type-specifier] [declaration-specifiers] ;
-> int [declaration-specifiers] ;
-> int [type-specifier] ;
-> int [typedef-name] ;
-> int [identifier] ;
-> int x ;
versus
[declaration] -> [declaration-specifiers] [init-declarator-list] ;
-> [type-specifier] [init-declarator-list] ;
-> int [init-declarator-list] ;
-> int [init-declarator] ;
-> int [declarator] ;
-> int [direct-declarator] ;
-> int [identifier] ;
-> int x ;
The standard resolves this ambiguity by having a constraint that is not
part of the context-free grammar. This ambiguity gets really nasty with
things like int f (x); -- is it a declaration of x with two type
specifiers or a declaration of f (a function with one parameter) with
with one type specifier?
A side-effect of this change is that the parser will now reject
declarations without any type specifiers at all, which probably makes
the error messages a bit less informative.
Nick Bowler [Sat, 25 Jun 2011 00:26:25 +0000 (20:26 -0400)]
Fix VPATH builds from git.
In such builds, C source files (that are normally distributed) get
generated, which means they end up in the build tree. Building them
subsequently fails because headers (in the source tree) are not found.
Nick Bowler [Thu, 23 Jun 2011 00:30:52 +0000 (20:30 -0400)]
Kill typemap_is_valid.
Just do the check when building the map in the first place. This
enables more useful error messages, too: the case where there are no
type specifiers at all is certainly worth diagnosing separately from
other kinds of nonsense.