Odd frame issue with inline

[rushmobius]

Stepping over the following code doesn't move to the trace(2), but jumps out. The trace(2) does execute. If I remove the inline from fetch, it works as expected. This is in the latest vscode/haxe/hashlink

class Cache
{
    public static inline function fetch<T>(?context:Int, type:Class<T>, redirects:Bool = true):T
    {
        return fetchInternal(context, type, redirects);
    }

    private static function fetchInternal<T>(?context:Int, type:Class<T>, redirects:Bool):T
    {
        return null;
    }
}

.. in a function

var b = true;

if (b)
{
    trace(1);
    var s = Cache.fetch(String);
    trace(2);
}

[Gama11]

inline means the function is not present in the output, so you can't really debug it. You could add --no-inline to your HXML for debugging to avoid that. Alternatively, -D keep-inline-positions may help.

[rushmobius]

It isn't so much debugging into the function. If you step over the trace(1), it jumps out of the current scope, completely skipping the next 2 lines even though it executes them. If I remove inline on the fetch function, i can step over all 3 lines.

The issue doesn't seem specific to inline. It seems to be inline function that has default/optional args. But that said, the compilation server doesn't consistently behave the same for this test.

[rushmobius]

I added the -D keep-inline-positions and still have the same behavior. Slightly simplified example below using the Cache class above. Set a breakpoint on trace(1). Run, hit the breakpoint and try to step forward once. It jumps up to the calling point for test().

` function test():Void { trace(1);

    var s = Cache.fetch(String);

    trace(s);
}

`

[ncannasse]

Thanks for the report, will look into it when I have time

[ncannasse]

The bug is actually a Haxe compiler bug, the -D dump shows the following:

        .20    @10 tovirtual 9,7
        .20    @11 callclosure 1, 3(6,9) // call to trace(1)
    ; ?:1
        .1     @12 null 10
    ; Main.hx:21
        .21    @13 global 11, 2
        .3     @14 true 2

Here we have a null value with an unknown file position (haxe compiler Ast.null_pos), so when we break here the debugger will loose the stack information, making it having such weird behavior. I'll open a bug on Haxe repo.