@laubzega: Please explain the status of this PR from your POV.

@oliverschmidt: Experimental code. May have to be scrapped in entirety or in part, depending on the evaluation by @vrubleg. Currently waiting for feedback.

Sorry that I'm so late. I tested this code on one of my projects. In most cases it works fine, except such situation:

.PROC testref
	JSR oam_rescroll
.ENDPROC

.PROC test2
.IFREF oam_rescroll
	.ASCIIZ "teststr1"
.ENDIF
.ENDPROC

.IFREF oam_rescroll
.PROC oam_rescroll
	.ASCIIZ "teststr2"
.ENDPROC
.ENDIF

It is expected that teststr1 is included into output, but there is teststr2 only, without teststr1.

I would provide FASMG as an example of an assembler where such tricks work without issues (but it is a multi-pass assembler). For example, this code shows the same situation, and it works as expected (testval2 is included into the final binary):

namespace testcaller
	dd testval
end namespace

namespace testifref
	if used testval
		testval2 dd 0xEE
	end if
end namespace

if used testval
	testval dd 0xFF
end if

mmh. the given example seems plausible to me - but i cant judge if that fix makes sense or what else it could break

@kugelfuhr comment? :)

I haven't exactly analyzed what the code changes do, but they are surprisingly simple for what they claim to do. And indeed a simple test shows serious problems.

Using this input which contains a forward reference inside a .proc:

.proc   proc
        lda     foo
        foo = 2
.endproc

.ifref  foo
        lda     #$00
.endif

the assembler prints test.s(2): Warning: Didn't use zeropage addressing for 'foo' and translates the input as follows:

000000r 1  AD 02 00             lda     foo
000003r 1                       foo = 2
000003r 1               .endproc
000003r 1
000003r 1               .ifref  foo
000003r 1                       lda     #$00
000003r 1               .endif
000003r 1

But with this patch, we get:

000000r 1               .proc   proc
000000r 1  AD 02 00             lda     foo
000003r 1                       foo = 2
000003r 1               .endproc
000003r 1
000003r 1               .ifref  foo
000003r 1  A9 00                lda     #$00
000005r 1               .endif
000005r 1

This means that the patch causes the assembler to somehow think that there's a symbol foo in the global namespace - but this is not true.

The whole reason for the problems with local scopes comes from the fact that any symbol used within a local scope may be a forward reference to a symbol in this or an embedded scope. Like proc::foo in the code above. The assembler cannot just reference a symbol with the same name in the global scope, since a local definition might follow. This is a larger problem buried deep in the design of the assembler and the reason why I said that the patch that claims to fix it is "surprisingly simple".

I don't know if it is possible to fix the PR. My gut feeling says that it needs more than a few lines of code changes.

Sound like the proposed fix is too simple. So converting this to draft as well

It requires a significant refactoring to make it working in all cases, it looks like it will require to make assembler multipass (like FASMG).