[Mesa-dev] glsl/glcpp: A bunch of pre-processor cleanups

[Carl Worth]

Here's my latest series of patches to improve conformance of glcpp, (the glsl
preprocessor in mesa).

Most of these changes are fixes that only a test-suite author could love. Most
fix nit-picky tests that do things that no sance application would actually
do. They're all reasonable things to do, but few are likely to impact many
real applications.

The entire series (as well as some earlier patches already reviewed) can be
found on the glcpp-fixup branch of my mesa tree:

	git://people.freedesktop.org/~cworth/mesa

Here's a run-down of what the changes are in this series:

Patch 01: Give an error for "#define 123" or similar non-identifier

	Not a useful thing to do, of course, but an error we need.

Patch 02: Support comment here: "#define /* Ha! */ FOO"

Patches 03-12: Many cleanups/rewriting while working on the next patch

Patch 13: Support comment here: "# /* Tricky! */ define FOO"

	Comments appearing in these places are not likely, but are clearly
	valid according to the language specification. There was a bunch of
	work necessary to make this fix easy, (and even with all the
	preliminary work, the final patch was longer than I wanted).

	I am happy that the lexer state at the end of this cleanup is much
	simpler and easier to read than it was before.

Patch 14: Emit internal error for unrecognized character

	This is to make un-subtle all classes of subtle bugs where the default
	flex rule was simply printing unrecongized characters to stdout and
	dropping them from the GLSL source.

	This is not actually in glcpp but in the lexer for the main glsl
	compiler.

Patch 15: Emit error for bogus extra characters after #extension

	This is an example of a fix for one of those subtle bugs from the flex
	default-rule. This is a patch from Ken that was sent some time ago.

Patches 16-17: Trivial fixups (renaming of token identifiers and new comment)

Patch 18: Emit an error for duplicate macro parameter, eg "#define FOO(a, a)"

Patch 19: Emit error if "++" or "--" appear in preprocessor condition

Patches 20-21: Two new tests for bugs that I wrote (and fixed) while working
               on some of the above.

Patch 22: Emit internal error for unrecognized character

	This is just like patch 14, but for the lexer in glcpp itself.

Patch 23: Treat '\r' as equivalent to '\n'

	The '\r' character was previously hitting the default lex, "print and
	throw away" rule so was being entirely ignored. With patch 22, '\r'
	would instead generate an internal error. Fix this by making '\r'
	equivalent to '\n'.

	I'd like to be even more spec-compliant for '\r', but I think this is
	OK for now. I'd also like to add some more-exhaustive testing for
	'\r', (such as running all of glcpp-test on the test cases with '\n'
	changed to "\r\n").