Dream Daemon & Seeker crashing/freezing for SS13

ID:2667038
 
Mar 23 2021, 12:49 pm
Resolved
The null-conditional ?. ?: and ?[] operators compiled incorrectly as of build 514.1550 in a way that caused major problems at runtime with some cases, and some really esoteric cases were incorrect or inefficient before that. The operators now have the correct precedence and association to behave as expected.
BYOND Version:514.1550
Operating System:Windows 10 Pro 64-bit
Web Browser:Chrome 89.0.4389.90
Applies to:Dream Maker
Status: Resolved (514.1552)
This issue has been resolved.
Descriptive Problem Summary:
Upon trying to boot SS13 via daemon or seeker, it crashes or freezes forever, respectively.

Image comparison between versions:
1549: https://i.imgur.com/3N4z8UY.png
1551: https://i.imgur.com/ihltFEZ.png (Daemon closes/crashes shortly after spawning a new child process)

Set as DM Language as it's probably something with the virtual machine or the emitted bytecode.


Numbered Steps to Reproduce Problem:
Attempt to run the game via seeker or daemon.

On Discord, you said you would accept SS13 as long as it doesn't use an external DLL.

So here's a link to download a ZIP of a compliant version: https://github.com/goonstation/goonstation/archive/refs/ heads/no-extern.zip

Or, here's the actual GitHub page: https://github.com/goonstation/goonstation/tree/no-extern

Expected Results:
Not crashing

Actual Results:
Daemon: Will boot and call world/New(), then crashes
Seeker: Will boot and call world/New(), then gets stuck and stays open forever, with the Options and Messages window staying open. Doesn't actually open the proper seeker client window.

Does the problem occur:
Every time? Or how often? Yes
In other games? Unknown
In other user accounts? Yes
On other computers? Yes

When does the problem NOT occur?
Old version

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? 514.1549

Workarounds: None

Mar 24 2021, 1:58 pm
So to follow up, I think I've fixed this after considerable work but boy is it gonna be a bitch to test.

We determined that compiling in 514.1549 did not cause the issue, and this is in fact a compiler problem. It relates to id:2569765 and probably more directly to id:2662224.

The workaround for the time being is to compile in 514.1549.
Mar 24 2021, 8:11 pm
Descriptive Problem Summary:
The behaviour of ?., ?:, and ?[] are a little cursed and have also changed between 513/514.

I'll just list out all the things I have found.

1) In 514.1551, `x?.y[z]` short-circuits to before the list access operation instead of after it. This means that the code will always runtime if x is null. This didn't happen in 513.1539.
/datum/var/y

/proc/test(x, z)
    return x?.y[z]

/world/New()
    test(null, 2)


2) In 514.1551, `x?[y].z` short-circuits to before the 'z' field access. The operator never existed in 513, but I'd expect it to cooperate with field accesses rather than doing this.
/datum/var/z

/proc/test(list/x, y)
    return x?[y].z

/world/New()
    test(null, 2)


3) In 514.1551, conditional list accesses don't chain with following normal list accesses. I'd expect it to just evaluate to null (like it would with field accesses) instead of hitting a runtime. This is all new stuff, so maybe it can just be labelled expected behaviour
/proc/test(list/x, y, z)
    return x?[y][z]

/world/New()
    test(null, 2, 3)


Mar 25 2021, 1:19 pm
In response to Willox
I've joined this issue to Zewaka's because it's all the same animal. I'm actually working on a test suite for all this stuff right now and will incorporate your cases.
Mar 26 2021, 3:01 pm
Lummox JR resolved issue with message:
The null-conditional ?. ?: and ?[] operators compiled incorrectly as of build 514.1550 in a way that caused major problems at runtime with some cases, and some really esoteric cases were incorrect or inefficient before that. The operators now have the correct precedence and association to behave as expected.