#321 Macros expanded or parsed inside if(0)/endif block, breaking some include-guards

[Anders Andersson]

I've been having issues writing code with multiple include files and include guards, and reduced it to a minimal example which I think should assemble without problems but does not:

    list p=16F84
any macro   parm
    movlw   #v(parm)
    endm

    if (0)
any macro   parm
    movlw   #v(parm)
    endm
    endif
    end

$ gpasm -S 2 guard.asm
guard.asm:9:Warning[206] Found call to macro in column 1: "any"
guard.asm:10:Error[101]   ERROR: (Symbol parm not assigned a value.)
Error[181]   Error generating hex file.
$ gpasm --version
gpasm-1.5.2 #1330 (Nov 16 2022)

Without -S 2 and the #v() construct, it will only issue the warning, but this showed up when I used #v() in a macro and I always assemble with -S 2 to catch mistakes.

Apparently the code inside the if (0)/endif pair is still assembled and macros expanded, leading to "garbage" expansion if a macro is defined twice.

I would like to be able to freely include multiple header files in any order, so I want to wrap them inside include guards, but this issue prevents that in some situations.

Is this perhaps just a bug in reporting errors? Because nothing else seems to assemble. Then again, the warning indicates that it at least tries to expand the macro somehow.

---

The example is of course contrieved but it shows up in structures such as:

debug.inc

    ifndef DEBUG_INC
DEBUG_INC EQU 1
; Should be guarded against multiple definitions
debug_wiggle macro pin
    movlw 1<<DEBUG_PIN#v(pin)
    xorwf DEBUG_PORT,f
    endm
    endif ; DEBUG_INC

uart.inc

    include "debug.inc"
transmit macro
    debug_wiggle 1
    ...
    endm

main.asm

    include "debug.inc"
    include "uart.inc"  ; Also includes debug.inc
    ...

[Petr Mikše]

I had this problem too. I got around this by putting the macro definitions in a second .inc file that was all conditionally included.