pret / pokeemerald

Decompilation of Pokémon Emerald
2.28k stars 2.55k forks source link

Pre-processing of enums for inclusion in assembly files does not handle non-numeric definitions #2019

Closed lhearachel closed 2 months ago

lhearachel commented 3 months ago

Use Case

enum {
    VALUE_0 = 0,
    VALUE_1, // 1
    VALUE_2, // 2
    VALUE_2a = VALUE_2, // implicitly, 2
};

Expectation

preproc should parse this enum definition appropriately and create a .set directive that assigns either VALUE_2 or 2 to VALUE_2a.

Reality

preproc fatals when it reaches VALUE_2a = VALUE_2:

error: expected number in included file <path/to/file:line>
SBird1337 commented 2 months ago

I looked at this issue thinking it was a quick fix. But it seems we will be running into more issues w.r.t. not correctly parsing C. This was pointed out in the original PR which I and some others agreed with, but deemed the ability to have support for enum at all more important.

The issue is as follows:

enum Bar {
    BAR_0 = 0,
    BAR_1 = 1,
};

enum {
    VALUE_0 = 0,
    VALUE_1, // 1
    VALUE_2, // 2
    VALUE_2a = BAR_1,
    VALUE_3
};

is correct C, and would yield VALUE_2a = 1 and VALUE_3 = 2 . While you could have .equiv VALUE_2a, BAR_1 as the output you'd also need to take care of the enum counter. (Here VALUE_3 = 2)

I think we could just retain a collection of enum variables in the current preproc TU in order to support this, but that's a little more work than I initially anticipated.