Remove blank lines from output files before comparing.

Recently I'm seeing cases where "gcc -E" mysteriously omits blank
lines, (even though it prints the blank lines in other very similar
cases). Rather than trying to decipher and imitate this, just get rid
of the blank lines.

This approach with sed to kill the lines before the diff is better
than "diff -B" since when there is an actual difference, the presence
of blank lines won't make the diff harder to read.

Implement token pasting of integers.

To do this correctly, we change the lexer to lex integers as string values,
(new token type of INTEGER_STRING), and only convert to integer values when
evaluating an expression value.

Add a new test case for this, (which does pass now).

Add placeholder tokens to support pasting with empty arguments.

Along with a passing test to verify that this works.

Provide support for empty arguments in macro invocations.

For this we always add a new argument to the argument list as soon as
possible, without waiting until we see some argument token. This does
mean we need to take some extra care when comparing the number of
arguments with the number of expected arguments. In addition to
matching numbers, we also support one (empty) argument when zero
arguments are expected.

Add a test case here for this, which does pass.

Make two list-processing functions do nothing with an empty list.

This just makes these functions easier to understand all around.  In
the case of _token_list_append_list this is an actual bug fix, (where
append an empty list onto a non-empty list would previously scramble
the tail pointer of the original list).

Avoid treating an expanded comma as an argument separator.

That is, a function-like invocation foo(x) is valid as a
single-argument invocation even if 'x' is a macro that expands into a
value with a comma. Add a new COMMA_FINAL token type to handle this,
and add a test for this case, (which passes).

Add support (and test) for an object-to-function chain with the parens in the content.

That is, the following case:

#define foo(x) (x)
#define bar
bar(baz)

which now works with this (ugly) commit.

I definitely want to come up with something cleaner than this.

Treat newlines as space when invoking a function-like macro invocation.

This adds three new pieces of state to the parser, (is_control_line,
newline_as_space, and paren_count), and a large amount of messy
code. I'd definitely like to see a cleaner solution for this.

With this fix, the "define-func-extra-newlines" now passes so we put
it back to test #26 where it was originally (lately it has been known
as test #55).

Also, we tweak test 25 slightly. Previously this test was ending a
file function-like macro name that was not actually a macro (not
followed by a left parenthesis). As is, this fix was making that test
fail because the text_line production expects to see a terminating
NEWLINE, but that NEWLINE is now getting turned into a SPACE here.

This seems unlikely to be a problem in the wild, (function macros
being used in a non-macro sense seems rare enough---but more than
likely they won't happen at the end of a file). Still, we document
this shortcoming in the README.

All macro lookups should be of type macro_t, not string_list_t.

This is what I get for using a non-type-safe hash-table implementation.

Implement (and test) support for macro expansion within conditional expressions.

To do this we have split the existing "HASH_IF expression" into two
productions:

First is HASH_IF pp_tokens which simply constructs a list of tokens.

Then, with that resulting token list, we first evaluate all DEFINED
operator tokens, then expand all macros, and finally start lexing from
the resulting token list. This brings us to the second production,
IF_EXPANDED expression

This final production works just like our previous "HASH_IF
expression", evaluating a constant integer expression.

The new test (54) added for this case now passes.

Fix lexing of "defined" as an operator, not an identifier.

Simply need to move the rule for IDENTIFIER to be after "defined" and
everything is happy.

With this change, tests 50 through 53 all pass now.

Implement #if and friends.

With this change, tests 41 through 49 all pass. (The defined operator
appears to be somehow broken so that test 50 doesn't pass yet.)

stash

Implement token pasting.

Which makes test 40 now pass.

Rename identifier from 'i' to 'node'.

Now that we no longer have nested for loops with 'i' and 'j' we can
use the 'node' that we already have.

Remove some stale token types.

All the code referencing these was removed some time ago.

Prevent unexpanded macros from being expanded again in the future.

With this fix, tests 37 - 39 now pass.

README: Document some known limitations.

None of these are fundamental---just a few things that haven't been
implemented yet.

Fix a typo in a comment.

Always better to use proper grammar in our grammar.

Expand macro arguments before performing argument substitution.

As required by the C99 specification of the preprocessor.

With this fix, tests 33 through 36 now pass.

Change macro expansion to append onto token lists rather than printing directly.

This doesn't change any functionality here, but will allow us to make
future changes that were not possible with direct printing.
Specifically, we need to expand macros within macro arguments before
performing argument substitution. And *that* expansion cannot result
in immediate printing.

Check active expansions before expanding a function-like macro invocation.

With this fix, test 32 no longer recurses infinitely, but now passes.

Defer test 26 until much later (to test 55).

Supporting embedded newlines in a macro invocation is going to be
tricky with our current approach to lexing and parsing. Since this
isn't really an important feature for us, we can defer this until more
important things are resolved.

With this test out of the way, tests 27 through 31 are passing.

Avoid getting extra trailing whitespace from macros.

This trailing whitespace was coming from macro definitions and from
macro arguments. We fix this with a little extra state in the
token_list. It now remembers the last non-space token added, so that
these can be trimmed off just before printing the list.

With this fix test 23 now passes. Tests 24 and 25 are also passing,
but they probbably would ahve before this fix---just that they weren't
being run earlier.

Remove a bunch of old code and give the static treatment to what's left.

We're no longer using the expansion stack, so its functions can go
along with most of the body of glcpp_parser_lex that was using it.

Avoid swallowing initial left parenthesis from nested macro invocation.

We weren't including this left parenthesis in the argument's token
list so the nested function invocation wasn not being recognized.

With this fix, tests 21 and 22 now pass.

Ignore separating whitespace at the beginning of a macro argument.

This causes test 16 to pass. Tests 17-20 are also passing now, (though
they would probably have passed before this change and simply weren't
being run yet).

Implement substitution of function parameters in macro calls.

This makes tests 16 - 19 pass.

Collapse multiple spaces in input down to a single space.

This is what gcc does, and it's actually less work to do
this. Previously we were having to save the contents of space tokens
as a string, but we don't need to do that now.

We extend test #0 to exercise this feature here.

Add a test #0 to ensure that we don't do any inadvertent token pasting.

This simply ensures that spaces in input line are preserved.

Pass through literal space values from replacement lists.

This makes test 15 pass and also dramatically simplifies the lexer.

We were previously using a CONTROL state in the lexer to only emit
SPACE tokens when on text lines. But that's not actually what we
want. We need SPACE tokens in the replacement lists as well. Instead
of a lexer state for this, we now simply set a "space_tokens" flag
whenever we start constructing a pp_tokens list and clear the flag
whenever we see a '#' introducing a directive.

Much cleaner this way.

Implement simplified substitution for function-like macro invocation.

This supports function-like macro invocation but without any argument
substitution. This now makes test 11 through 14 pass.

Implement #undef.

Which is as simple as copying the former action back from the git
history.

Now all tests through test 11 pass.

Implement expansion of object-like macros.

For this we add an "active" string_list_t to the parser. This makes
the current expansion_list_t in the parser obsolete, but we don't
remove that yet.

With this change we can now start passing some actual tests, so we
turn on real testing in the test suite again. I expect to implement
things more or less in the same order as before, so the test suite now
halts on first error.

With this change the first 8 tests in the suite pass, (object-like
macros with chaining and recursion).

Make the lexer pass whitespace through (as OTHER tokens) for text lines.

With this change, we can recreate the original text-line input
exactly. Previously we were inserting a space between every pair of
tokens so our output had a lot more whitespace than our input.

With this change, we can drop the "-b" option to diff and match the
input exactly.

Store parsed tokens as token list and print all text lines.

Still not doing any macro expansion just yet. But it should be fairly
easy from here.

Delete some trailing whitespace.

This pernicious stuff managed to sneak in on us.

Add xtalloc_reference.

Yet another talloc wrapper that should come in handy.

Starting over with the C99 grammar for the preprocessor.

This is a fresh start with a much simpler approach for the flex/bison
portions of the preprocessor. This isn't functional yet, (produces no
output), but can at least read all of our test cases without any parse
errors.

The grammar here is based on the grammar provided for the preprocessor
in the C99 specification.

Add test for '/', '<<', and '>>' in #if expressions.

These operators have been supported already, but were not covered in
existing tests yet. So this test passes already.

Add test of bitwise operators and octal/hexadecimal literals.

This new test covers several features from the last few commits.

This test passes already.

Add support for octal and hexadecimal integer literals.

In addition to the decimal literals which we already support. Note
that we use strtoll here to get the large-width integers demanded by
the specification.

Switch to intmax_t (rather than int) for #if expressions

This is what the C99 specification demands. And the GLSL specification
says that we should follow the "standard C++" rules for #if condition
expressions rather than the GLSL rules, (which only support a 32-bit
integer).

Add the '~' operator to the lexer.

This was simply missing before, (and unnoticed since we had no test of
the '~' operator).

Implement all operators specified for GLSL #if expressions (with tests).

The operator coverage here is quite complete. The one big thing
missing is that we are not yet doing macro expansion in #if
lines. This makes the whole support fairly useless, so we plan to fix
that shortcoming right away.

Implement #if, #else, #elif, and #endif with tests.

So far the only expression implemented is a single integer literal,
but obviously that's easy to extend. Various things including nesting
are tested here.

Implement (and add test) for token pasting.

This is *very* easy to implement now that macro arguments are pre-expanded.

Pre-expand macro arguments at time of invocation.

Previously, we were using the same lexing stack as we use for macro
expansion to also expand macro arguments. Instead, we now do this
earlier by simply recursing over the macro-invocations replacement
list and constructing a new expanded list, (and pushing only *that*
onto the stack).

This is simpler, and also allows us to more easily implement token
pasting in the future.

Add xtalloc_asprintf

I expect this to be useful in the upcoming implementation of token pasting.

Finish cleaning up whitespace differences.

The last remaining thing here was that when a line ended with a macro,
and the parser looked ahead to the newline token, the lexer was
printing that newline before the parser printed the expansion of the
macro.

The fix is simple, just make the lexer tell the parser that a newline
is needed, and the parser can wait until reducing a production to
print that newline.

With this, we now pass the entire test suite with simply "diff -u", so
we no longer have any diff options hiding whitespace bugs from
us. Hurrah!

Avoid printing a space at the beginning of lines in the output.

This fixes more differences compared to "gcc -E" so removes several
cases of erroneously failing test cases. The implementation isn't very
elegant, but it is functional.

Fix bug of consuming excess whitespace.

We fix this by moving printing up to the top-level "input" action and
tracking whether a space is needed between one token and the next.

This fixes all actual bugs in test-suite output, but does leave some
tests failing due to differences in the amount of whitespace produced,
(which aren't actual bugs per se).

Remove unused function _print_string_list

The only good dead code is non-existing dead code.

Remove "unnecessary" whitespace from some tests.

This whitespace was not part of anything being tested, and it
introduces differences (that we don't actually care about) between the
output of "gcc -E" and glcpp.

Just eliminate this extra whitespace to reduce spurious test-case
failures.

Stop ignoring whitespace while testing.

Sometime back the output of glcpp started differing from the output of
"gcc -E" in the amount of whitespace in emitted. At the time, I
switched the test suite to use "diff -w" to ignore this. This was a
mistake since it ignores whitespace entirely. (I meant to use "diff
-b" which ignores only changes in the amount of whitespace.)

So bugs have since been introduced that the test suite doesn't
notice. For example, glcpp is producing "twotokens" where it should be
producing "two tokens".

Let's stop ignoring whitespace in the test suite, which currently
introduces lots of failures---some real and some spurious.

Add test (and fix) for a function argument of a macro that expands with a comma.

The fix here is quite simple (and actually only deletes code). When
expanding a macro, we don't return a ',' as a unique token type, but
simply let it fall through to the generic case.

Add support for commas within parenthesized groups in function arguments.

The specification says that commas within a parenthesized group,
(that's not a function-like macro invocation), are passed through
literally and not considered argument separators in any outer macro
invocation.

Add support and a test for this case. This support makes a third
occurrence of the same "FUNC_MACRO (" shift/reduce conflict appear, so
expect that.

This change does introduce a fairly large copy/paste block in the
grammar which is unfortunate. Perhaps if I were more clever I'd find a
way to share the common pieces between argument and argument_or_comma.

Avoid re-expanding a macro name that has once been rejected from expansion.

The specification of the preprocessor in C99 says that when we see a
macro name that we are already expanding that we refuse to expand it
now, (which we've done for a while), but also that we refuse to ever
expand it later if seen in other contexts at which it would be
legitimate to expand.

We add a test case for that here, and fix it to work. The fix takes
advantage of a new token_t value for tokens and argument words along
with the recently added IDENTIFIER_FINALIZED token type which
instructs the parser to not even look for another expansion.

Use new token_list_t rather than string_list_t for macro values.

There's not yet any change in functionality here, (at least according
to the test suite). But we now have the option of specifying a type
for each string in the token list. This will allow us to finalize an
unexpanded macro name so that it won't be subjected to excess
expansion later.

Perform "re lexing" on string list values rathern than on text.

Previously, we would pass original strings back to the original lexer
whenever we needed to re-lex something, (such as an expanded macro or
a macro argument). Now, we instead parse the macro or argument
originally to a string list, and then re-lex by simply returning each
string from this list in turn.

We do this in the recently added glcpp_parser_lex function that sits
on top of the lower-level glcpp_lex that only deals with text.

This doesn't change any behavior (at least according to the existing
test suite which all still passes) but it brings us much closer to
being able to "finalize" an unexpanded macro as required by the
specification.

Remove unused NEWLINE token.

We fixed the lexer a while back to never return a NEWLINE token, but
negelcted to clean up this declaration.

Remove unneeded YYLEX_PARAM define.

I'm not sure where this came from, but it's clearly not needed.

Rename yylex to glcpp_parser_lex and give it a glcpp_parser_t* argument.

Much cleaner this way, (and now our custom lex function has access to
all the parser state which it will need).

Add a wrapper function around the lexer.

We rename the generated lexer from yylex to glcpp_lex. Then we
implement our own yylex function in glcpp-parse.y that calls
glcpp_lex. This doesn't change the behavior at all yet, but gives us a
place where we can do implement alternate lexing in the future.

(We want this because instead of re-lexing from strings for macro
expansion, we want to lex from pre-parsed token lists. We need this so
that when we terminate recursion due to an already active macro
expansion, we can ensure that that symbol never gets expanded again
later.)

Like previous fix, but for object-like macros (and add a test).

The support for an object-like amcro within a macro-invocation
argument was also implemented at one level too high in the
grammar. Fortunately, this is a very simple fix.

Fix bug as in previous fix, but with multi-token argument.

The previous fix added FUNC_MACRO to a production one higher in teh
grammar than it should have. So it prevented a FUNC_MACRO from
appearing as part of a mutli-token argument rather than just alone as
an argument. Fix this (and add a test).

Fix bug (and test) for an invocation using macro name as a non-macro argument

This adds a second shift/reduce conflict to our grammar. It's basically the
same conflict we had previously, (deciding to shift a '(' after a FUNC_MACRO)
but this time in the "argument" context rather than the "content" context.

It would be nice to not have these, but I think they are unavoidable
(withotu a lot of pain at least) given the preprocessor specification.

Fix bug (and add tests) for a function-like macro defined as itself.

This case worked previously, but broke in the recent rewrite of
function- like macro expansion. The recursion was still terminated
correctly, but any parenthesized expression after the macro name was
still being swallowed even though the identifier was not being
expanded as a macro.

The fix is to notice earlier that the identifier is an
already-expanding macro. We let the lexer know this through the
classify_token function so that an already-expanding macro is lexed as
an identifier, not a FUNC_MACRO.

Rewrite macro handling to support function-like macro invocation in macro values

The rewrite her discards the functions that did direct, recursive
expansion of macro values. Instead, the parser now pushes the macro
definition string over to a stack of buffers for the lexer. This way,
macro expansion gets access to all parsing machinery.

This isn't a small change, but the result is simpler than before (I
think). It passes the entire test suite, including the four tests
added with the previous commit that were failing before.

Add several tests where the defined value of a macro is (or looks like) a macro

Many of these look quite similar to existing tests that are handled
correctly, yet none of these work. For example, in test 30 we have a
simple non-function macro "foo" that is defined as "bar(baz(success))"
and obviously non-function macro expansion has been working for a long
time.  Similarly, if we had text of "bar(baz(success))" it would be
expanded correctly as well.

But when this otherwise functioning text appears as the body of a
macro, things don't work at all.

This is pointing out a fundamental problem with the current
approach. The current code does a recursive expansion of a macro
definition, but this doesn't involve the parsing machinery, so it
can't actually handle things like an arbitrary nesting of parentheses.

The fix will require the parser to stuff macro values back into the
lexer to get at all of the existing machinery when expanding macros.

Fix (and add test for) function-like macro invocation with newlines.

The test has a newline before the left parenthesis, and newlines to
separate the parentheses from the argument.

The fix involves more state in the lexer to only return a NEWLINE
token when termniating a directive. This is very similar to our
previous fix with extra lexer state to only return the SPACE token
when it would be significant for the parser.

With this change, the exact number and positioning of newlines in the
output is now different compared to "gcc -E" so we add a -B option to
diff when testing to ignore that.

Expect 1 shift/reduce conflict.

The most recent fix to the parser introduced a shift/reduce
conflict. We document this conflict here, and tell bison that it need
not report it (since I verified that it's being resolved in the
direction desired).

For the record, I did write additional lexer code to eliminate this
conflict, but it was quite fragile, (would not accept a newline
between a function-like macro name and the left parenthesis, for
example).

Fix bug (and add test) for a function-like-macro appearing as a non-macro.

That is, when a function-like macro appears in the content without
parentheses it should be accepted and passed on through, (previously
the parser was regarding this as a syntax error).

Add test and fix bug leading to infinite recursion.

The test case here is simply "#define foo foo" and "#define bar foo"
and then attempting to expand "bar".

Previously, our termination condition for the recursion was overly
simple---just looking for the single identifier that began the
expansion. We now fix this to maintain a stack of identifiers and
terminate when any one of them occurs in the replacement list.

Fix two whitespace bugs in the lexer.

The first bug was not allowing whitespace between '#' and the
directive name.

The second bug was swallowing a terminating newline along with any
trailing whitespace on a line.

With these two fixes, and the previous commit to stop emitting SPACE
tokens, the recently added extra-whitespace test now passes.

Don't return SPACE tokens unless strictly needed.

This reverts the unconditional return of SPACE tokens from the lexer
from commit 48b94da0994b44e41324a2419117dcd81facce8b .

That commit seemed useful because it kept the lexer simpler, but the
presence of SPACE tokens is causing lots of extra complication for the
parser itself, (redundant productions other than whitespace
differences, several productions buggy in the case of extra
whitespace, etc.)

Of course, we'd prefer to never have any whitespace token, but that's
not possible with the need to distinguish between "#define foo()" and
"#define foo ()". So we'll accept a little bit of pain in the lexer,
(enough state to support this special-case token), in exchange for
keeping most of the parser blissffully ignorant of whether tokens are
separated by whitespace or not.

This change does mean that our output now differs from that of "gcc -E",
but only in whitespace. So we test with "diff -w now to ignore those
differences.

Add test with extra whitespace in macro defintions and invocations.

This whitespace is not dealt with in an elegant way yet so this test
does not pass currently.

Provide implementation for macro arguments containing parentheses.

We were correctly parsing this already, but simply not returning any
value (for no good reason). Fortunately the fix is quite simple.

This makes the test added in the previous commit now pass.

Add test invoking a macro with an argument containing (non-macro) parentheses.

The macro invocation is defined to consume all text between a set of
matched parentheses. We previously tested for inner parentheses from a
nested function-like macro invocation. Here we test for inner
parentheses occuring on their own, (not part of another macro
invocation).

Fix expansion of composited macros.

This is a case such as "foo(bar(x))". The recently added test for this
now passes.

Add test for composed invocation of function-like macros.

This is a case like "foo(bar(x))" where both foo and bar are defined
function-like macros. This is not yet parsed correctly so this test
fails.

Eliminate a shift/reduce conflict.

By simply allowing for the argument_list production to be empty rather
than the lower-level argument production to be empty.

Support macro invocations with multiple tokens for a single argument.

We provide for this by changing the value of the argument-list
production from a list of strings (string_list_t) to a new
data-structure that holds a list of lists of strings
(argument_list_t).

Add test for function-like macro invocations with multiple-token arguments.

These are not yet parsed correctly, so these tests fail.

Make macro-expansion productions create string-list values rather than printing

Then we print the final string list up at the top-level content
production along with all other printing.

Additionally, having macro-expansion productions that create values
will make it easier to solve problems like composed function-like
macro invocations in the future.

Move most printing to the action in the content production.

Previously, printing was occurring all over the place. Here we
document that it should all be happening at the top-level content
production, and we move the printing of directive newlines.

The printing of expanded macros is still happening in lower-level
productions, but we plan to fix that soon.

Remove _list suffix from several identifiers.

Instead of "parameter_list" and "replacement_list" just use
"parameters" and "replacements". This is consistent with the existing
"arguments" and keeps the line length down in the face of the
now-longer "string_list_t" rather than "list_t".

Rename list_t and node_t to string_list_t and string_node_t.

We'll soon be adding other types of lists, so it will be helpful to
have a qualified name here.

Fix case of a macro formal parameter matching a defined macro.

Simply need to allow for a macro name to appear in the parameter list.

This makes the recently-added test pass.

Add test where a macro formal parameter is the same as an existing macro.

This is a well-defined condition, but something that currently trips up
the implementation. Should be easy to fix.

Implement substitution of macro arguments.

Making the two recently-added tests for this functionality now pass.

Add tests exercising substitution of arguments in function-like macros.

This capability is the only thing that makes function-like macros
interesting. This isn't supported yet so these tests fail for now.

Make the lexer return SPACE tokens unconditionally.

It seems strange to always be returning SPACE tokens, but since we
were already needing to return a SPACE token in some cases, this
actually simplifies our lexer.

This also allows us to fix two whitespace-handling differences
compared to "gcc -E" so that now the recent modification to the test
suite passes once again.

Makefile: Make "make test" depend on the main program.

Otherwise, running "make test" can run an old version of the code,
(even when new changes are sitting in the source waiting to be
compiled).

Add some whitespace variations to test 15.

This shows two minor failures in our current parsing (resulting in
whitespace-only changes, oso not that significant):

  1. We are inserting extra whitespace between tokens not originally
     separated by whitespace in the replacement list of a macro
     definition.

  2. We are swallowing whitespace separating tokens in the general
     content.

Fix parsing of object-like macro with a definition that begins with '('.

Previously our parser was incorrectly treating this case as a
function-like macro. We fix this by conditionally passing a SPACE
token from the lexer, (but only immediately after the identifier
immediately after #define).

Add test for an object-like macro with a definition beginning with '('

Our current parser sees "#define foo (" as an identifier token
followed by a '(' token and parses this as a function-like macro.

That would be correct for "#define foo(" but the preprocessor
specification treats this whitespace as significant here so this test
currently fails.

Eliminate a reduce/reduce conflict in the function-like macro production.

Previously, an empty argument could be parsed as either an "argument_list"
directly or first as an "argument" and then an "argument_list".

We fix this by removing the possibility of an empty "argument_list"
directly.

Add support for the structure of function-like macros.

We accept the structure of arguments in both macro definition and
macro invocation, but we don't yet expand those arguments. This is
just enough code to pass the recently-added tests, but does not yet
provide any sort of useful function-like macro.

Add tests for the structure of function-like macros.

These test only the most basic aspect of parsing of function-like
macros.  Specifically, none of the definitions of these function like
macros use the arguments of the function.

No function-like macros are implemented yet, so all of these fail for
now.