Typecompletion issue with Haxe 3.4

[Glidias]

Haxe 3.3 doesn't have this issue. Looks like type-completion is completely broken in Haxe 3.4. You have to use Haxe 3.3 for now.

In Haxe 3.4, eg. var gun = _gun.get(entity);
Accessing any of the items like _gun. or gun. yields a vomit/rubbish typehinting list output of all Haxe's compile time metadata fields in alphabetical order.

eg. @:abi, @:abstract, @:access ......@:volatile
No relavant typehinting information is shown.

BTW, I encountered a similar issue with my framework HaxeVx before (between Haxe 3.3 and Haxe 3.4). I did a change for my framework some time ago that fixed this similar-looking issue Glidias/haxevx@5c15f58 , but for your case, it might be different, as I absolutely do not know the underlying cause of this issue.

BTW, the commit description is wrong (it has nothing to do with :keep, any metadata name will also trigger it), as I didn't know the cause of the issue. I just removed something off to avoid the problem altogether. It appears (on further investigation) like I couldn't add a build field's metadata annotation whose position pos:... is set to Context.getLocalClass().get().pos (using something like Context.currentPos) is fine. Note, however,, for mine case, what happens is that it shows the correct type-hinting initially, then after some lag time, it kills off the typehinting and spills out the rubbish @: metadata list. For your case, it happens immediately. Not sure if that difference matters or not.. Your case is likely to be entirely different as I don't see any explicit cases similar to mine in your codebase, and I removed the meta: reference in FieldsBuilder.as, but it doesn't change anything.

NOTE: For your case, the typehinting issue seems to ONLY occur inside the override function update() method of a given System. If placed anywhere else, (eg. _gun.) in constructor of class, it's fine, for example. Weird! What's so special about update()??

[Glidias]

Ok, found a way to "fix" it. Since the problem occurs only inside the update() function of your System class, it's the SystemBuilder.hx that is the culprit, with field.meta.push( { name: ":unreflective", pos: field.pos } over the implementation's update() function field using pos:field.pos doesn't play nicely with Haxe 3.4 (ie. appears as if dynamically added metadata's pos value cannot exist as part of the class field/class position reference??), . If i used another kind of position like Context.getPosition( for the meta:{pos:..}), typehinting problem is avoided. But still, I don't understand why this is the case for Haxe 3.4 (obviously, since i don't know the haxe source code), and it's something that I hope the Haxe team can fix that. (edit: I know why somewhat this is the case...but not necessarily why it's only for Haxe 3.4)

Then again, come to think of it, dynamically added metadata (which would obviously be invisible to the user/coder) should NOT have it's position tied to an actual field position anyway, since you can't jump to to such a position anyway from your IDE (as you can't even 'see' it..lol), it would theoritically be considered "undefined" position. Of course, there is no "undefined" position in Haxe API because pos is a compulsory field. Thus, maybe it makes "more sense" to use Context.getPosition() for such cases...lol...

[eliasku]

👍👍👍👍👍

Could you check the latest core? I've merged your changes, seems like it will not reproduce anymore and we will close that issue right after you verify it.
Personally I use IntelliJ IDEA, so I had no issues with autocompletion previously