"expected statement" bug in IOS builds

[Dave Dyer]

Re: an old thread
https://groups.google.com/forum/#!searchin/codenameone-discussions/statement$20expected%7Csort:relevance/codenameone-discussions/jBNoy1bSKM4/ZrW5in1dCwAJ

This is still an extant problem that crops up randomly; today I got to the bottom of it.  The problem
is that the asm package is generating duplicate labels, albeit in different classes.  Of itself this
is probably not a problem, but parpavm maintains a static global list of used labels.  When one
of these unused but duplicate labels appears at the end of a function, xcode is unhappy.

Here's the direct evidence from one of my recent builds

G:\temp\btest\build\dist\Launch-src>grep -i "L590511187" *

com_codename1_ui_Display.m:label_L590511187:
online_game_commonCanvas.m:label_L590511187:
online_game_commonCanvas.m:    if (ilocals_8_<ilocals_9_) /* IF_IMPLT CustomJump */ goto label_L590511187;

The best way to fix it is not completely obvious - does this really need to be a global static set?  It seems
likely to me that the maximum scope of a label is a single method.

[Shai Almog]

I don't recall the exact reason/logic by now but I think I wrote the whole global label list to allow throw and similar behaviors to work correctly.
Maybe the solution is to append the class name to the label values.

Steve?

[Dave Dyer]

The fix I'm using is to use the label object itself instead of toString as the key.
If you look at the code, there are already several other collections of labels
that do.

[Steve Hannah]

Can you share a little bit more of the problematic  code that is generated in the grep?  Does the build error correspond directly to one of those lines?  I'd like to understand more about the problem before simply making a change to the static global label set.

Ideally, I'd like to see the Xcode error along with the C source in and around the error position.

Steve

--
You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codenameone-discussions+unsub...@googlegroups.com.
Visit this group at https://groups.google.com/group/codenameone-discussions.
To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/1cc6f977-3efc-4ed8-803f-b4d0ad442986%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Steve Hannah

Software Developer

Codename One

http://www.codenameone.com

[Dave Dyer]

There's nothing special about the code.  Yes, it corresponds directly.

the "islabelused" logic normally deletes unused labels, but the aliased label identity
causes the label to be retained.  Normally this is harmless, but if it occurs as the
last statement in a function, the compiler is unhappy.