Assert failure when aliasing a variable with a given address

[undisbeliever]

Minimal reproducible test case:

bank ram      @  0x200  : [vardata;    0x600];
bank code     @ 0x8000  : [constdata; 0x8000];

var byteVariable @ 0x1234 : u8;

in code {
    var test : u8 in byteVariable;
}

* wiz: version 0.1.2 (alpha)
>> Parsing...
>> Compiling...
wiz: src/wiz/utility/optional.h:112: T& wiz::Optional<T>::get() & [with T = long unsigned int]: Assertion `hasValue_' failed.

The test will compile successfully (with test pointing to the correct address) if the in code { line is replaced with in ram {.

[shinymerlyn]

I also ran into this same exact issue, with the same assert with the same stack trace.

Here's a different repro that more closely matches how I bumped into this problem:

bank code     @ 0x8000  : [constdata; 0x8000];

in code {
    var test : u8 in y;
}

This assert is partially blocking me working on patches to fix the other bugs I've reported.

To work around the problem locally, I'm doing a <xyz>.hasValue ? <xyz>.get() : 0 in each of the places where I am experiencing an assert. I seem to be getting the same binary results out, so that seems to be an okay workaround for now. When I tried just commenting out the assert, it seemed to access random data from memory and ended up with a super large storage size and not zero (and thus not successfully finishing the compile). So I'm not sure what a release build does in this case.

[shinymerlyn]

Here's my patch. I don't know that passing a storage size of 0 is the right behavior, nor that it matches what happens in a release build (when the assert doesn't fire, but it doesn't generate a giant binary either), so that's why I'm not submitting it as a PR.

I can submit it if that is determined to be the right fix tho, if you like. Please let me know.