Compiler hanging after std file diagnostic

[RblSb]

When you have "haxe.diagnosticsPathFilter": ".*?" in your vscode settings.json.

Try to go to definition on Bytes and haxe will be in dead loop.

function main() {
	trace(haxe.io.Bytes.alloc(0));
}

-cp src
-main Main
--js bin/main.js

Full project: aendless.zip

[RblSb]

Regression in https://github.com/HaxeFoundation/haxe/commit/2f6c55d13aa24a610829cd391ad2b109f71e9678 @kLabz, can you please restore that branch and maybe check what happened?

[kLabz]

I cannot repro the issue at all.

Maybe you have something in your global vscode configuration that has an impact here?

[RblSb]

Tested without other settings, only thing that causes this bug is "haxe.diagnosticsPathFilter": ".*?" and haxe.executable set to dev build.

This is what happens for me with after first Go to definition on haxe.io.Bytes on js target, haxe hangs with 100% single thread and eating 200MB ram every second until you restart compilation server.

https://github.com/user-attachments/assets/3d0cd22a-78cd-4a0b-80cf-ee4147647e24

(vscode 1.100.2, macos 14.7.6, vshaxe 2.34.1)

process_sample.txt

[RblSb]

Reverting this change fixes endless loop for me https://github.com/HaxeFoundation/haxe/pull/11722/commits/720d806e5e9c00a20712b44aa54ac194fe488149 But if i do Reload window in vscode while having focus on /std/js/_std/haxe/io/Bytes.hx tab (that i opened from go to definition), there is still 100% cpu hanging with both cases. If i just remove hctx.com.display <- ... line, then there is no problems. Idk what this line does, maybe this field should be restored after display request or something.

[kLabz]

That change should not be reverted. But I can't do much without being able to repro :/

[RblSb]

Are you sure you enabled diagnostics for std files and see red stuff inside them, if you change some type to wrong.Path?

I debugged a little and found that if i change dms_display_file_policy = DFPAlso to DFPNo there is no hanging, so i found place where its handled and that if i comment out only this line there is no loop: https://github.com/HaxeFoundation/haxe/blob/caaec6918c20b4cdb9391069d4ee125d753a2188/src/compiler/displayProcessing.ml#L158 Freeze happens inside of this call that never ends (in first line of finalize method) https://github.com/HaxeFoundation/haxe/blob/caaec6918c20b4cdb9391069d4ee125d753a2188/src/compiler/compiler.ml#L320 But that's probably useless info, so i minimized Bytes impl to:

package haxe.io; // std/haxe/io

class Bytes {
	function new(data:Int) {}
}


package haxe.io; // /std/js/_std/haxe/io

@:coreApi
class Bytes {
	function new(data:Int) {}
}

Changing Int to some.unknown.Type in _std implementation will provide correct "Module not found" diagnostics error. But if you change it into Int2 or any other random name like Abc, there will be no Unknown identifier : Int2 error (if class has @:coreApi meta) and compiler endlessly tries to find that type. If i change it back to some.Int2, search is ended again with correct "module not found" error.

So basically @:coreApi _std class in display mode cannot find BytesData, but haxe can find it in non-display mode and resolve correctly without full haxe.io module path.

Upd: if i comment out this block, Unknown identifier error will be back. Calling do_load_core_class is problematic. https://github.com/HaxeFoundation/haxe/blob/caaec6918c20b4cdb9391069d4ee125d753a2188/src/context/typecore.ml#L644-L655

[kLabz]

Diagnostics are called, don't hang, and do return. I can't get far enough to have red stuff inside because of the _std issue, but that's something else (which I should look at soon).

{"jsonrpc":"2.0","id":30,"result":{"timers":{"children":[{"name":"other","path":"other","info":"","time":0.005989867029711604,"calls":0,"percentTotal":73.53510407227959,"percentParent":73.53510407227959},{"name":"parsing","path":"parsing","info":"","time":0.00161305395886302,"calls":1,"percentTotal":19.802791973648507,"percentParent":19.802791973648507}],"name":"","path":"","info":"","time":0.008145588566549122,"calls":208,"percentTotal":100,"percentParent":0},"result":[{"file":null,"diagnostics":[{"kind":2,"severity":1,"range":null,"args":"Invalid commandline class : js._std.haxe.io.Bytes should be haxe.io.Bytes","code":null,"relatedInformation":[]}]}],"timestamp":1749098963.348628}}

[kLabz]

I managed to reproduce a similar behavior by hacking the compiler; this might get rid of the hang: https://github.com/HaxeFoundation/haxe/tree/refs/heads/display-vs-_std (though more stuff is needed to make display API actually work there)

[RblSb]

@kLabz https://github.com/HaxeFoundation/haxe/commit/b911546018381df5c70cc2ed9c4ee40b59cf4db7 commit helps with hanging. Do you think this one is not good enough yet to be pushed?

[Simn]

That commit kinda looks like it shouldn't be a thing, but then that's probably mostly because this special _std handling shouldn't be a thing in the first place... so I think it's fine?

[kLabz]

Yeah.. but need to find what I did back then to repro and remember what I was talking about there:

more stuff is needed to make display API actually work there