Support static for locals

[Simn]

There's still some work to be done here.

There's some particular problem with completion due to the parser now picking up static at expression-level. In the failing tests this causes something that's supposed to be a class field to be parsed as an expression, which then leads to wrong completion. I already tried looking into it but got a headache.

[Simn]

The display issue is this: When parsing blocks in the display file, the parser goes into Hail Mary mode and ignores any sort of "deep" error, trying to parse the block no matter what. It will only stop if its "next element" function comes across something that is not the start of a valid block element, at which point it closes the block.

What changed here is that now static is the start of a valid block element, so what used to be a "no match" failure is now one of these "deep" errors that block parsing ignores. We can see this in one of the failing tests:

class Main {
	@:debug.display
	static function main() {
		test({
		
	}
	static function test(o:{a:Float, b:String}) {}
}

Requesting completion at test({| gives us this:

  56- 127 EBlock
  61-  84   ECall
  61-  65     test
  66-  75     EBlock
  78-  84   null
  85- 124   EFunction
 122- 124     EBlock

That null expression comes from the static while the parser is hail marying, and then the EFunction is function test parsed as a local function. This then causes the actual static function test to not exist, and thus expected type completion fails.

This shouldn't be a new issue, at the very least it should be reproducible with inline as well. I'm not sure right now how to address this without making the parser indentation-aware in some way.

[Simn]

For the time being I will just change the tests. This is a very specific problem that requires a certain constellation to reproduce, which is going to be a rare occurrence in practice. We should still look into how to handle these kinds of parser resuming problems, but that's a separate topic altogether.

[back2dos]

If it's any consolation, I would argue this is not really a regression, because it's no different from this:

class Main {
        static function main() {}
	@:debug.display
	function wip() {
		test({
		
	}
	function test(o:{a:Float, b:String}) {}
}

This makes test disappear from completion all the same. Using an IDE one rarely runs into the scenario, because parens / braces are balanced upon insertion.

---

All that being said, I wonder whether it wouldn't be better for "Hail Mary mode" to assume that any keyword that can begin a field is the start of a field. Worst case you get completion for things that are intended to be not-yet-declared local functions / vars. Seems a better tradeoff then loosing all the following fields that have no access modifier.

[Simn]

Good point about plain old function also causing that.

I'm not sure about the tradeoff you mention though. I would prefer no completion over any sort of completion that causes broken code if "accepted", because that is way more irritating.

[Simn]

For now we'll just error in case of a naming conflict, and go for a simple functionname_localname mangling. I'm not sure if it's worth doing something more elaborate here. We could try to apply local variable renaming to static locals as well, but I don't know if we should given that we don't allow conflicts for real statics either. But if anyone has strong feelings about that, we can discuss it again.