Support closured vars inside Const initializer

[RX14]

Probably isn't the cleanest fix, but this solves it with the least changes.

I found another bug with const initializer codegen while I was solving this, that's why there's 2 commits.

Fixes #10474 .

[RX14]

Seems the alpine build failing is pre-existing, the windows build failing is ???

I think I should not test CONST being 0, since it's nil and the value is undefined?

[asterite]

This is great! I think if we name it def instead of fake def then it's much better. That is, this is the correct solution, not a temporary one.

[RX14]

I'd prefer to name it this way, since it is a fake def, the function it refers to never gets defined, and does not exist in the program. The Def exists only to provide a context to type the initializer in.

[asterite]

I see. Yeah, that makes sense.

[RX14]

A more complete refactor I think would make the proc initializers actual Defs in the AST, which are treated mostly normally (i.e. actually visited by the visitors), just with special name mangling and are called as the const initializer. But this works, for now.

[straight-shoota]

I'd say the windows failure is an actual bug. The CONST value should really be nil, it's not undefined.
And converting nil to an integer shouldn't give 699531520.

[RX14]

@straight-shoota I think the values here are not actual nil.to_i, this would perform normally in a real system, it's just weirdness coming from uninitialized memory and the JIT.

At least, without doing some unsafe memory wrangling.

[RX14]

In llvm, %Nil = type {}, and it has zero length. I think this is fine, nil has no binary representation. Especially since unions of nil are optimized.

[RX14]

Yeah, sizeof(Nil) == 0, so pointerof(nil_var).unsafe_as(Pointer(UInt8)).value is reading the byte in memory after the nil value, theoretically.

[RX14]

Just to further make sure that that spec is correct: https://carc.in/#/r/aibt

[straight-shoota]

Okay 👍 Then maybe the spec could check CONST.nil??

[RX14]

done!

[RX14]

bump?

[asterite]

Looks good, thank you!

I still think fake_def should be just renamed to def. It doesn't matter if it's "fake" or that we fake it: in the end we end up kind of creating a def for it. But this rename get to into a later PR if needed.