z00m128
Struct with "local" name can't be used in non-local way
MODULE Whatever
MethodA:
STRUCT .Data ; local to MethodA
X1l BYTE
X2l BYTE
ENDS
Md .Data { 12, 34 } ; <- WORKS in v1.21.0
STRUCT Data ; inside module (standalone)
X1m BYTE
X2m BYTE
ENDS
STRUCT @Data ; global (no module prefix)
X1g BYTE
X2g BYTE
ENDS
Md2 MethodA.Data { 12, 34 } ; <- FAILS in v1.21.0
; ^ error: Unrecognized instruction: MethodA.Data { 12, 34 }
ENDMODULE
MahInstanceGlob Data { 12, 34 }
MahInstanceMod Whatever.Data { 12, 34 }
MahInstanceLoc Whatever.MethodA.Data { 12, 34 } ; <- FAILS in v1.21.0
; ^ error: Unrecognized instruction: Whatever.MethodA.Data { 12, 34 }
ld a,(MahInstanceGlob.X1g)
ld a,(MahInstanceMod.X1m)
ld a,(MahInstanceLoc.X1l)
Decide if this is wanted feature to be fixed and make it work, or forbid local names for structures and error out already on the definition.
From debugging: this is fairly broken in multiple ways, some bugs even cancelling each other out...
Currently this local name .Data is used as "id" inserted into structures list (with two of them the two are created with identical id in the linked list), the anti-duplicate check does look for module..Data which is never inserted so it never finds duplicate and the final labels with struct size and offsets are inserted with correct module.main.Data labels so they don't collide for two .Data structs.
I think the most proper fix is to create full struct name (what is the final label name currently) as early as possible and use that also as "id" value, thus stored struct will have full name and duplicate search will look for full name (and find it in case of duplicate).
Maybe insert the full label early (at start of struct parsing) to both construct it and check for duplicate, then just update the value with struct size upon end of struct parsing? Removing some of the custom code to detect dupes as that will be handled by labels code. Maybe even have label trait struct-main and search for rest of struct definition for such labels.
Or maybe add extra pointer/index to labels which would index into list of structs, but there's no good current member to be hijacked for union/dual purpose, so it would enlarge the labels element for real (and the label element could use some compacting/refactoring itself, it's a bit mess right now with extension on extension).
That's the creation side...
TODO: review usage side, how the instruction parsing looks for struct names, make it label-like namespace searching so it will find also fully qualified or partial names of structures, and decide based on that how exactly to refactor structs, if it's really good idea to pull it toward labels map or keep that separated and rework independent structs list (maybe switch to map with fully qualified names how macros are done). Or maybe check if this can merge with macros.
Your above example should definitly not raise 'Unrecognized instruction' error.
But if the fix is complicated, I would postpone it to a 2.x branch (if you plan to go so far). This is because I really think the entire namespace behaviour needs a deep refactoring, and things should be more coherent (for example, the concept of module should be dropped, in profit of a more generic namespace macro which could be used anywhere).
I think I'm confused, the module is pretty much namespace thing, so I'm struggling to figure out which part is not coherent, it should be pretty coherent as is already in current version (except bugs in implementation like this one).
Then there are design questions like whether macros should be inside (change) or outside namespace (current), but that's currently "coherent" in its own way, depends from which angle you look at it (macros are like preprocessor step while modules/namespace is like compile time step affecting symbols, but from practical point having namespaced macros could have value too). So it doesn't feel to me like there's some obvious huge incoherence in module stuff, if you feel like that, then either I forgot about some part or I have my perception bent by knowing the implementation, so for me it "makes sense" and I'm blind to the problems/issues. :)
Feel free to open new issues with examples what would you expect and how current version behaves to open my view a bit (I'm not promising to change the assembler, but it's always good to be aware of different views).
About this issue: it's just straight bug, v1.21.0 not working as advertised. Local names for structs are not advertised in docs, so I can "fix" it just by disabling them, but the implementation is still horribly broken even for regular ones, it works well in correct cases, but any error state is handled more like by accident and not by the code which should have handled it. :) So this needs fixing, I just need some quality-coding time at home, and that's not happening lately.
I need to take the time to summurize this module vs namespace I have in mind...