Hi everyone,

I had already reported the issue as
<http://bugs.freepascal.org/view.php?id=30626>, but as this problem is currently blocking a clean solution in a project for us, I'm asking for help again here.

The problem appears to be that when a generic uses its type parameter to inline-specialize another generic (ie. inherit from it), that generic cannot be specialized anywhere else (ie. return value of that type) or a name collision occurs. Not really sure why that happens, but for some reason the compiler doesn't recognize that the two instances don't have the same name by accident but really are the same type.

Do you have any idea what could be done to work around this?

Thank you in advance,

Martok

Good evening,

it appears we have been able to fix this issue. Please see the attached patch and example program.

The problem is that when a specialization occurs as a resultdef, this symbol is put into the local symtable. It is not previously present there, so a new one is added. CheckDuplicate then finds a name collision from this symtable to the parent symtable, where it was already defined via inheritance, raising a Duplicate Identifier error.

The same happens when the same type specialization is used as a return type in different classes, so it's not just this specific case.

The fix is to use the same logic as checkduplicate in FindWithHash for tObjectSymtable and tLocalSymtable and also check parent symtables for specialization names that are visible in the current context.

Before submitting this to the bugtracker, 3 questions: does this look sane in general? We reuse internalerror 200602061 as this is raised for the exact same error cause, is this style okay or should it get a fresh number? To transform the example project into a testsuite test, what would be required?

Please let me know what you think,

Martok

"Martok" wrote

Before submitting this to the bugtracker, 3 questions: does this look

sane in

general?

I'll try to take a look at it this weekend. But at work we're currently rather busy (shortly before a new release of our main software), so no promises though... (As I'd really like to have a relaxing weekend for once ;) )

We reuse internalerror 200602061 as this is raised for the exact same error cause, is this style okay or should it get a fresh number?

Please use a new one. The idea of the internal errors is that the error location can be easily found even without a callstack.

To transform the example project into a testsuite test, what would be required?

If the bug report already has an example that should be fine, except you have other cases that aren't covered by that one.

Regards,
Sven