Discussion:
Generics: issue with double inline specialization
(too old to reply)
Martok
2016-09-30 22:14:33 UTC
Permalink
Raw Message
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

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Martok
2016-10-24 19:01:52 UTC
Permalink
Raw Message
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
Sven Barth
2016-10-26 21:54:38 UTC
Permalink
Raw Message
Post by Martok
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
;) )
Post by Martok
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.
Post by Martok
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

Loading...