FWD » Core Development » Conversion Tools

On a whim last night, I tried to compile the partially converted customer app project, and quickly hit an "illegal start of expression" error in many places. This was due to something like:

void myMethod( /* comment */, arg1, ...)

It looks like the test in brew's next-child rules for a star comment when emitting the comma is looking ahead instead of behind in this case.

I suggest to disable comments, run conversion in the good directories and compile again, to uncover non-comment problems.

I believe this was also addressed in the #1450. Unfortunately it was not finalized.

The code looks fine. And that is some testcase! It made me laugh to read it. Well done.

I still have some regressions in it, I'm testing and will re-upload.

The conclusion for today, after trying a scoping approach to solve some nested calls issues is this, in brew phase (a few examples):
1. this.getChildAt(nextChildIndex - 1).type should be written as this.getPrevChildNonStar().type
2. nextChildIndex > 1 should be written as getNonStarIndex(this, nextChildIndex) > 1
3. nextChildIndex 1 should be written as getNonStarIndex(this, nextChildIndex) 1
4. and others

What I'm trying to say here is that it will be cleaner (and easier) to modify the next-child-rules part to act as if the star nodes are not there. As we have only a move-forward phase provided by next-child-rules section where we can act on children, and not a "child-finished-rules" section to be able to look backwards, trying to fix next-child-rules feels like chasing my own tail. It will be very ugly and in the end I will still not be sure that I will cover all cases.

I am fine with the changes. If they pass conversion testing, let's go with it.

I'm running conversion now.

1. numberOfChildren
2. nextSibling
3. getChildAt
4. numImmediateChildren

Well done. It looks good. Painful, though. I have to think about this problem a bit to see if there is a way to help this in the future in TRPL.

OK, the server's compilable folders do not seem to report any comment-related errors. I'm putting this through conversion testing (comments disabled).

1. new-lines no longer emitted in some cases (i.e. between inner classes)
2. additional ';' character emitted on an empty line or at the end of a "//" comment

I'm running another conversion with comments enabled, to check if it compiles. I will fix the two issues before releasing the update.

MAJIC has compiled with comments enabled (and AFAIK this was not possible before this update).

WOW! That is very cool. Great job!

The server folders had no errors related to comments.

Committed to bzr revision 10251.

There is a problem when the comment is emitted after the peer:

def var i as int.
case i:
when 0 then /* v0 */ 
  assign i = i + 0.
when 1 then /* v1 */
  assign i = i + 0.
end.

            switch ((i).intValue())
            {
               case 0:
               {
                  i.assign(plus(i, 0));
                  break;
               }
 /* v0 */               case 1:
               {
                  i.assign(plus(i, 0));
                  break;
               }
 /* v1 */;
            }

At this time, I'm not sure if we really need to emit the comment after the code where it was in the legacy code... can you explain a little why you chose this approach in comments.rules?

wrong task

wrong task

wrong task

I agree. The approach you have taken is fine for now.

I also agree that we will need to make additional changes to the comments processing. At a minimum, the way we associate comments with surrounding code needs improvement.

The idea of bypassing artificial nodes sounds good, but I have to look carefully at the impact before I can really say.

Anyway, if this passes testing, you can release it.

ca_upd20130322i.zip was committed to bzr revision 10320. MAJIC conversion regression testing has passed (with comments disabled and enabled), and also the server folders seem to have accepted it (no comment related errors in logs).