Duplicate debug label error when two private enum types have the same name in a unit
## Summary
When compiling a unit with two classes that have their own private types and the private types have the same name, then the compilation fails with an assembly error about duplicate labels.
This does not happen when trying to compile a program, only a unit.
## System Information
- **Operating system:** Linux
- **Processor architecture:** x86-64
- **Compiler version:** trunk (a3f221e189506777dd25308f67ed457ad121352e)
- **Device:** Computer
## Steps to reproduce
Try to compile the following code:
```pascal
unit Parts;
{$mode objfpc}
{$scopedenums on}
interface
type
TFoo = class
private type
TPart = (Foo, Bar);
private
Part: TPart;
end;
TBar = class
private type
TPart = (Baz, Bad);
private
Part: TPart;
end;
implementation
end.
```
Using the following command:
```fpc -gw parts```
You will get something like:
```
Free Pascal Compiler version 3.3.1 [2023/10/06] for x86_64
Copyright (c) 1993-2023 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling parts.pas
parts.pas(10,5) Note: Private field "TFoo.Part" is never used
parts.pas(17,5) Note: Private field "TBar.Part" is never used
parts.pas(23) Error: Asm: Duplicate label DBG_$PARTS_$$_TPART
parts.pas(23) Error: Asm: Duplicate label DBGREF_$PARTS_$$_TPART
parts.pas(23) Fatal: There were 2 errors compiling module, stopping
Fatal: Compilation aborted
```
Note that compilation works if no debug is requested. Also disabling scoped enums does not affect this, however it should not really matter (both scoped and non-scoped should work).
## Example Project
See above.
## What is the current bug behavior?
Compilation fails.
## What is the expected (correct) behavior?
Compilation should work, private types with the same name should not affect any other types.
## Relevant logs and/or screenshots
See above
## Possible fixes
Perhaps labels for private types should use their container types as a prefix (also consider the case of nested private types - i.e. a private type defined inside another private type - trying that also produces the same error with the same labels as above).
issue