Fixed anonymous struct completion

[RSDuck]

I've put some research into the data the language server spits out and it seemed like the extension never gets informations about the field names.

The reason for this is, that the extension asks the language server for top level completion. The fix was pretty easy, I just had to edit the function which checks wether to use top level completion.

This should fix https://github.com/vshaxe/haxe-languageserver/issues/21

[Gama11]

From that diff it looks like you accidentally reverted some changes I made in da80752.

[Gama11]

Also, this seems to stop working with the test case from HaxeFoundation/haxe#3907 if there is a space before the cursor after the opening {.

Works:
doStuff({|

Doesn't work:
doStuff({ |

[Gama11]

This should also be removed.

[RSDuck]

Ah, sorry. I'm not very used to the code base

[Gama11]

I had to move the \s into the capture group for the whitespace fix to actually work.

[Gama11]

Thanks, seems to work nicely now!

I don't particularly like that completion needs to be triggered manually here, maybe we can improve that in the future.

[RSDuck]

I just noticed that the pattern has some serious flaws(I should have tested it on real code). For example when you have a structure containing other structures(it doesn't work recursively). Also when having operators in function it also doesn't work.

Here some examples:

test({
twoSquared: 2*2, // Breaks suggestion
person: new Person({firstName: "Bill", surname: "Gates"}) // Breaks also the suggestions for the following code
});

[Gama11]

Yeah, deciding whether to trigger field or toplevel completion actually gets quite complex in the case of struct completion, I don't think a regex will do long-term... For metadata and field completion it's not so bad.

Any ideas how Haxe could assist with this @Simn / @nadako?

[Simn]

Even the compiler doesn't know that you're declaring a structure until it sees the :, so this is always going to be an issue.

[nadako]

Today I found out that the reStructPart regexp added in 6fa2284 is so heavy it can hang the language server completely for minutes in a large file. I don't quite understand how does it work, so I'm inclined to revert that change for now... I'll try taking a closer look at it, but in general, regex hacks like these should go away when we use hxparser and incremental compilation.