Compiler Fails On Deutsch Grammar

Description

This is how to reproduce this bug:

cdg deutsch
compile

Result output:

cdgp> compile
INFO: translating current grammar to `deutsch.c'
INFO: compiling `deutsch.c' to `deutsch.o'
Detaching after fork from child process 1138.
deutsch.c: In function `_evalConstraint_478':
deutsch.c:21730: error: parse error before '!=' token
deutsch.c:21731: warning: left-hand operand of comma expression has no effect
deutsch.c:21731: warning: left-hand operand of comma expression has no effect
deutsch.c:21731: error: parse error before ':' token
deutsch.c:21741: warning: left-hand operand of comma expression has no effect
deutsch.c:21744: error: parse error before '||' token
deutsch.c:21821: warning: no return statement in function returning non-void
ERROR: compiler error, message should have been provided

The corresponding lines in deutsch.c look like this:

( /* lookup */ 
(lookupStrings[0] = (
((vs0.data.string = lv1->modifier->lexem->word), VTString)!= VTString ?
(cdgPrintf(CDG_WARNING, "WARNING: .... find_OBJD_anchor\n"), NULL) :
vs0.data.string)),
(lookupStrings[1] = ( // chokes here 
!= VTString ?
(cdgPrintf(CDG_WARNING, "WARNING: ... find_OBJD_anchor\n"), NULL) :
lv1->label)), ...

There's no code being generated at the indicated position See find_OBJD_anchor to get a constraint failing to be compiled.

Looking at the comTranslageLookup() reveils a series of errors and misconceptions in generating the lookup code. At least the following errors are there:

• a global array looukStrings is constructed that tries to collect all strings of all arguments of the lookup() predicate. this seriously fails on nested calls to lookup(). one should allocate space on the stack whenever nesting is an issue.
• the order of generated code is wrong, i.e. the error checking code preceeds the error producing code
• return types aren't handled thoroughly. The code relies on the arguments to be either RTSTring or a RTPeek.

To sum up: the lookup() predicate cannot be optimized during compile time (easily at least). Any posibile case distinction on the arguments will posibly break things more easily than any performance gain might be measurable. Therefore the compiler should generate code that calls funcLookup() directly. The complexity of funcLookup() is dominated by strAppend(). This is the place where optimization should happen, and help the constraint interpreter as well as the constraint compiler.

To optimizing funcLookup() is another bugreport, that is by refactoring the key generation into a multi-string-hash-function, that does not rely on strings being alligned in an adjacent way in memory. The current string hashing only needs adjacent strings to itterate over them and compute the hash value. This requirement is obviously over the edge.

Comments