[Bug] Nested Types, Constants are not autocompleted if they are preceded by an incomplete `if`

[BigBoyBarney]

Hi!

The following code snippet illustrates the issue. I have a feeling this might not be easy 😰

test :: proc () {
	pokemon: Snorlax
	if // pokemon does not appear as an autocomplete here, because Snorlax is invalid due to the incomplete if
	
	Snorlax :: struct {}
}

This issue does not require the Type to be directly under the incomplete if.

Everything is "invalid" until the `if` is closed, and nothing is autocompleted.

---

A "solution" is to close the incomplete if with {}, but it's somewhat cumbersome to do.

---

I'm not too hopeful about this, so feel free to close this issue if it's impossible, but I thought I'd mention it regardless.

Cheers!

[BigBoyBarney]

Actually, this applies to for as well.

[BradLewis]

Interestingly when you don't have thing after the if yet, so

test :: proc () {
	pokemon: Snorlax
	if // I get correct completions for "pokemon" here
	
	Snorlax :: struct {}
}

works fine, but if I start typing a p, then I no longer get it. eg

test :: proc () {
	pokemon: Snorlax
	if po // trigger here
	
	Snorlax :: struct {}
}

From what I can see, the parser puts the first thing you add in the init part of the if statement and the second in the cond part. When the declaration is part of the init then it works fine but when it gets pushed to the cond we lose all the information about it.

So this would likely require an update to the odin parser, but even then I'm not entirely sure how we would cleanly resolve this, as in how we could determine that the Snorlax declaration is intended to be after the if.

[BigBoyBarney]

Would it be possible to cut it off at the newline? Similar to how it's cut off at the first { encountered, which is why adding {} helps.

It doesn't solve the entire issue, but it covers pretty much all of it, as the only thing that would be valid on the next line is {