SjASMPlus от z00m

[Ped7g]

Так то бог с ним, сломал и сломал, просто надо выпилить из синтаксиса и убрать из доков.

Ah, interesting, but I think I know what is happening.

The line `call test1` is inside module `test`, so it has ambiguous interpretation, it can be either `call test.test1` calling another inside-module label, or it can be interpreted as `call test1` in global namespace without module.

If you remove the `IFUSED` test, the global `test1` will be defined, and in second+ pass the `call` will find it and use it, interpreting it as global label.

But with the `IFUSED` the global label is never defined, and the `call` will always trigger only the "in-module" interpretation (marking "test.test1" label as "used + not_defined", but that's not relevant to the `IFUSED` in include file, so that will be always false).

You can either use the other syntax of `IFUSED` after the label ("style1a"/"style1b" in my previous example, which do define the global label even when the label is unused, and the code is skipped, i.e.:

test1   IFUSED
            ret
        ENDIF

Or you can disambiguate the call line by using `call @test1` to make it clear the "test1" is label from global name space, not belonging to current `test` module.

(I guess you do not want the `test1` to belong into module `test`, otherwise also defining the `test1` routine inside the module will fix the error too, but then you have `test.test1` routine, not `test1`).

To fix this (in relaxed syntax way, allowing the source you posted as valid) the `call` would have to generate ambiguous two-variant "possibly used label" meta data, and the IFUSED would have to check all these variants then... Which is unfortunately not trivial fix. (and without thinking about it properly, I would be afraid of such change to backfire by having old source in modules generating suddenly lot more global undefined+used labels in the table, but maybe that's no issue at all, I don't know)

(and I'm not a big fan of relaxed syntax which has ambiguous interpretations, so I'm a bit tempted to fix this by removing "style2" syntax of IFUSED ... ... and also remove the global labels search when inside the module, to make the `@` mandatory in this case ... that would be like "correct" fix by my taste, but I guess that's not helping to actual users :P )

So at this moment I don't want to try to fix this, IMO either using the `@` or the "style1a" IFUSED syntax is good-enough workaround? But I should probably add this bug description to IFUSED docs as known bug.

Sorry for the inconvenience, I hope you can manage around this... (and of course thank you for the report)

[Advertiser]

[krt17]

Проблема лишь в том что в старом синтаксисе не работает, а в новом работает, почему в одном случае оно помечает использование в глобальных а во втором нет? У меня не так много включаемых библиотек, я просто их поправил. Глобальный поиск по собаке из модулей наверное правильно, пожалуй переделаю свои потихоньку, через пару лет.