Cannot use the +/- anonymous labels preceding a macro call

[svallee-dev]

Found another issue, something that used to work before but is now throwing an error: whenever I have a "+" or "-" anonymous label on a line where I call a macro, I'm getting this error:

Cannot redefine "+".

For instance:

GetWritePtr
		lda zp_write_buffer
		beq +
		.SET16 BC, RAMMap.Map1
		rts
+		.SET16 BC, RAMMap.Map0
		rts

(note that my macro does not contain a + label, which was my first guess).

Using an anonymous label seems to always work fine if I use it on a non-macro instruction. For instance if I add a "nop" instruction on the + line in the example above, it compiles without errors.

[informedcitizenry]

Again, I think the culprit may be your macro. Here is my mock-up of your code, all compiles fine.

SET16   .macro v1, v2
        tax
        lda \v1
        sta (0,x)
        lda \v2
        sta (1,x)
        .endmacro

BC = 3
zp_write_buffer = 0

GetWritePtr
		lda zp_write_buffer
		beq +
		.SET16 BC, RAMMap.Map1
		rts
+		.SET16 BC, RAMMap.Map0
		rts

    .namespace RAMMap
Map1    .word ?
Map0    .word ?
    .endnamespace

[svallee-dev]

Thank you for looking into all of them! Not sure how they are not replicable on your side but I'll try to dig more and find better repro steps.

The +/- breaking my Macros with a "Cannot redefine +" error happens 100% of the time on my side. Does not matter which macro I use, and all these macros works fine when used without a preceding +/-.

Here's more context that maybe matters: the code breaking by using +/- before a macro are inside various block/endblock, and the macros are defined outside of these blocks.

[informedcitizenry]

Just curious, does the layout of the blocks look something like this?

someblock  .block

    GetWritePtr
    		lda zp_write_buffer
    		beq +
		.SET16 BC, RAMMap.Map1
		rts

    someother .block

    +		.SET16 BC, RAMMap.Map0

              .endblock

		rts

           .endblock

[informedcitizenry]

Just a final follow-up on this. I believe the issue may have been you were referencing anonymous labels out of scope. Can you confirm?