Handle local labels correctly

[grahambates]

All labels are currently treated as unique global symbols and are suggested as completions anywhere in the project.

Labels with a dot prefix are contextual to their parent label. The same local label name can be defined multiple times in different contexts. It only makes sense to offer local labels as a completion when in the relevant scope.

The simplest solution for all of this is to prefix local labels when defining and looking up symbols, effectively name-spacing them to their parent label.

e.g.

Main:
.example

would be stored internally as Main.example

[prb28]

Hi,
I've a question about this one.
Do you think that the sub function label beginning with "." is a common use?
Will it not be rejected by some users that have another way of organizing labels?
We have talk about this topic in this issue: #147
And I don't really have a clear idea of the generalization of this , even if I would use this rule.

[prb28]

One more thing, there is a test failing:

1. Completion Tests
   Completion api
   Should not return a completion on a local label out of scope:
   AssertionError: .empty was passed non-string primitive undefined
   at Context. (out/test/completion.test.js:143:42)

[grahambates]

Hi, I've a question about this one. Do you think that the sub function label beginning with "." is a common use? Will it not be rejected by some users that have another way of organizing labels? We have talk about this topic in this issue: #147 And I don't really have a clear idea of the generalization of this , even if I would use this rule.

The use of a dot prefix for local labels is actually a defined behaviour of the assembler, not just a naming convention based on personal preference.

From the VASM manual:

Local labels are preceded by ’.’ or terminated by ’$’. For the rest, any alphanumeric character including ’_’ is allowed. Local labels are valid between two global label definitions.

Until I looked it up just now I wasn't even aware of the '$' suffix variant. TIL! I've never seen this in the wild but we should probably support that too. Devpac supported the _ character for this purpose too and vasm will optionally support this with the -localu command line option.

This change just makes symbol references work as per that description. If users don't use local labels then this wouldn't affect them.

For example, the following is perfectly valid:

GlobalLabel1:
.localLabel:
  bra .localLabel
  rts

GlobalLabel2:
.localLabel:
  bra .localLabel
  rts

Notice there are two instances of .localLabel but this is allowed because their scope is limited by the two global labels. The bra operations reference the .localLabel within the same scope. If you tried to do this without the dot prefix you'd get a duplicate symbol error. This is commonly used for loops within routines using short labels like .l without having to worry about them being globally unique.

With the previous behaviour, all symbols are treated as global and M68kDefinitionHandler would only store a reference to one .localLabel symbol definition in its labels Map. It would also suggest labels that are not present in the current scope as completions. Adding a prefix to the map key solves this problem.

Hopefully I managed to explain this clearly enough! Let me know if not. That test should be fixed now.

[prb28]

Thanks for this explanation. Much clearer for me now.