Untraslatable goto-s about jsil

[kg]

This usually indicates that the compiler generated a goto that the current goto translation algorithm can't express correctly in JS. I think it's possible to express it but the current algorithm needs to be rewritten to support it. I haven't yet encountered any code that actually depends on these gotos.

[matra774]

The code tha depends is quite simple. Here is the examlpe:
IEnumerable strings = Enumerable.Repeat("I like programming.", 15);

With ILSPY it decompiles into:

// System.Linq.Enumerable.<CreateRepeatIterator>d__57<TResult>
bool IEnumerator.MoveNext()
{
switch (this.<>1__state)
{
case 0:
    this.<>1__state = -1;
    this.<i>5__58 = 0;
    break;

case 1:
    this.<>1__state = -1;
    this.<i>5__58++;
    break;

default:
    goto IL_6D;
}
bool result;
if (this.<i>5__58 >= this.count)
{
    IL_6D:
    result = false;
}
else
{
    this.<>2__current = this.element;
    this.<>1__state = 1;
    result = true;
}
return result;
}

The problem is the goto IL_6D in the first switch, which actually just jumps into another if statement, which sets the result to false.

The JSIL generates the following code:

$asm03.System.Linq.Enumerable.$lCreateRepeatIterator$gd__57$b1.prototype.IEnumerator_MoveNext = function () {
var __label0__ = "__entry0__";
__step0__:
while (true) {
    switch (__label0__) {
        case "__entry0__":
            switch (this.$state) {
                case 0:
                    this.$state = -1;
                    this.i = 0;
                    break;
                case 1:
                    this.$state = -1;
                    ++this.i;
                    break;
                default:
                    JSIL.UntranslatableInstruction("goto", "IL_6D");
            }
            if (this.i >= this.count) {
                var __label1__ = "__entry1__";
                __step1__:
                while (true) {
                    switch (__label1__) {
                        case "__entry1__":
                            __label1__ = "IL_6D";
                            continue __step1__;
                            break;
                        case "IL_6D":
                            var result = false;
                            break __step1__;
                    }
                }
            } else {
                this.$current = this.element;
                this.$state = 1;
                result = true;
            }
            return result;
            break __step0__;
    }
}
};

[kg]

I think your problem is fixed by 94fe808.

[kg]

Closer examination revealed a second bug where the body of the if statement's true clause was left empty when I hoisted the label out of it. That bug is particularly sneaky because you can't reproduce it with hand-written C#; only IL produced by the C# compiler for yield return contains gotos structured like this.