Describe the bug
When compiling a struct with an unoptimized math expression, the compiler will optimize it, but only after the expression has been hoisted outside of the function itself. This affects DELTARUNE Chapter 5 in a bunch of code entries.
To Reproduce
Example code that can do this:
Expected behavior
Since we can't know what the original expression was, we need to decide how to somehow un-optimize the expression in the decompiler. Doing something like * 1 could do the trick, but that may look ugly and be unclear as to intent. Maybe we could add some kind of special comment like /// @optimized to be clear about the intent? Not sure... (Seems like it could get ugly in certain cases.)
Describe the bug
When compiling a struct with an unoptimized math expression, the compiler will optimize it, but only after the expression has been hoisted outside of the function itself. This affects DELTARUNE Chapter 5 in a bunch of code entries.
To Reproduce
Example code that can do this:
a = { b: 2 * 2 };Expected behavior
Since we can't know what the original expression was, we need to decide how to somehow un-optimize the expression in the decompiler. Doing something like
* 1could do the trick, but that may look ugly and be unclear as to intent. Maybe we could add some kind of special comment like/// @optimizedto be clear about the intent? Not sure... (Seems like it could get ugly in certain cases.)