PR# 15241 Sequence of changes causes syntax error in generated C code

A sequence of changes (reproducible from attached BACKUP.tar file created using
automatic_backup in config file) causes C code generated by a freeze to fail
to compile due to a syntax error.

Here is the C code for the `make' routine that won't compile, with the 
offending line marked by "==>":

/* {TEST}.make */
void F586_6176 (EIF_REFERENCE Current)
{
        GTCX
        char *l_feature_name = "make";
        RTEX;
        EIF_TYPED_VALUE up1x = {0, SK_POINTER};
#define up1 up1x.it_p
        EIF_TYPED_VALUE ur1x = {0, SK_REF};
#define ur1 ur1x.it_r
        EIF_REFERENCE tr1 = NULL;
        RTCDT;
        RTSN;
        RTDA;
        RTLD;

        RTLI(3);
        RTLR(0,Current);
        RTLR(1,tr1);
        RTLR(2,ur1);
        RTLU (SK_VOID, NULL);
        RTLU (SK_REF, &Current);

        RTEAA(l_feature_name, 585, Current, 0, 0, 8247);
        RTGC;
        RTSA(dtype);
        RTSC;
        RTDBGEAA(585, Current, 8247);
        RTIV2(Current, RTAL);
        RTHOOK(1);
  ==>   tr1 = ((up1x = (FUNCTION_CAST(EIF_TYPED_VALUE, (EIF_REFERENCE)) RTVF(585, 8, "out", Current))(Current))), ((up1x.type == SK_REF)? (EIF_REFERENCE) 0: (up1x.it_r = RTBU(up1x))), (up1x.type = SK_POINTER), up1x.it_r);
        ur1 = RTCCL(tr1);
        (FUNCTION_CAST(void, (EIF_REFERENCE, EIF_TYPED_VALUE)) RTWF(585, 25, dtype))(Current, ur1x));
        RTVI2(Current, RTAL);
        RTRS;
        RTHOOK(2);
        RTDBGLE;
        RTLE;
        RTLO(2);
        RTEE;
#undef up1
#undef ur1
}

Use the attached BACKUP.tar file.
First compilation was in batch mode (ec -config test.ecf).
All the rest of the compilations were done in one estudio session.
I could not reproduce this outside estudio, so I couldn't write an eweasel test.
However, I did reproduce it using estudio, so you should be able to reproduce it.
Note that class invariants are monitored.

Possibly important note:  Even though compilation_info.txt for COMP13 says
it was a quick melt, I actually did a Finalize (keeping assertions).  Don't
know if that is relelvant.

This is fixed in rev#81696.

You are right. I'm not sure how could my testing not revealed that. I'm putting a fix in the compiler now.

I think I see why this bug is still present, despite the supposed fix
in rev 81575. 

In FEATURE_BL, `is_right_parenthesis_needed' is a once function
that returns a CELL [BOOLEAN].   Routine `generate_end' in FEATURE_BL
calls `generate_access_on_type' and expects it to set
`is_right_parenthesis_needed' to the correct value.  The version of
that routine in FEATURE_BL always sets `is_right_parenthesis_needed'
but a descendant FEATURE_BW redefines `generate_access_on_type' to
call `generate_workbench_access_on_type' which does not appear to
set `is_right_parenthesis_needed'.  Thus when I do a workbench 
compilation after finalizing and keeping assertions, the value of `is_right_parenthesis_needed'
is the one set by the previous finalize.

I hope with this analysis you can fix this bug for 6.5.

This bug was supposedly fixed in rev 81575 but if I follow the instructions
for the bug entry on 5/7/2009, freezing still fails with a C compilation error.
I'm using 6.5.81614 (release candidate), so it should have the fix but
the problem still occurs.  I hope this can really be fixed for 6.5 since we ran
into it while doing real work.

Reopening report.

This is fixed in rev#81575.

Note this happens without a precompiled library too.

Note that exiting EiffelStudio and then touching the class(es) in which the C compilation errors occur and call freeze again would fix the C compilation problem.

It seems that we generate an extra `)' and most likely one of our once strings gets modified via the finalization without assertions.

One of our developers just ran into this bug and spent awhile trying to
figure out what was wrong.  Please up the priority of this bug.

In Eiffel Studio 6.5.8.524 GPL Edition - windows, the bug is reproducible indeed with the steps David wrote in last interaction. The C error when freezing is:

Error code: C Compiler Error

Error: External C/C++ compilation failed.
What to do: Check the external C/C++ compilation for details.

Error C2440: '=' : cannot convert from 'EIF_TYPED_VALUE' to 'EIF_REFERENCE'

I did some more investigation into this bug and the results were truly
surprising.  It turns out that this is not an incrementality bug in the usual
sense of the word.  It can be reproduced without any changes to any classes
or to the configuration file, after initial compilation.

To reproduce the bug:

1. Start estudio and compile with the attached class and config file (melt).
   The class just has a creation procedure that does `print (out)'.
2. Finalize, keeping assertions.  No need to do C compilations.
3. Freeze, with C compile.  C compilations fail due to a syntax error in the
   code generated for {TEST}.make.  There is an extra parenthesis.

If you delete the EIFGENs tree and freeze from scratch with C compilation, it
works fine.  Very strange.

I added eweasel test incr325 for this bug, but for reasons I don't understand
the test always passes.  One has to do the above steps in one estudio session
to generate workbench C code with a syntax error.

I think this deserves to be inv
....
Output truncated, Click download to get the full message

Attachments for problem report #15241