[fpc-devel] RTTI for ProcVar types

Sven Barth pascaldragon at googlemail.com
Sat Mar 30 18:50:58 CET 2013


On 30.03.2013 17:34, Steve Hildebrandt wrote:
>> Am 25.03.2013 10:01, schrieb Sven Barth:
>>> Am 24.03.2013 22:49, schrieb Steve Hildebrandt:
>>>> Am 24.03.2013 22:26, schrieb Sven Barth:
>>>>> I don't know immediately how you can differentiate between
>>>>> anonymous types and named ones, but that would be the key difference.
>>>> Since the function building the name usied to access the RTTI table
>>>> uses only the smytables to decide weather the type is annonymous or
>>>> referenced by it's name I thought that approach was ok.
>>>> (symdef.pas 1434)
>>>>     function Tstoreddef.rtti_mangledname(rt:trttitype):string;
>>>>      ...
>>>>         if assigned(typesym) and
>>>>            (owner.symtabletype in [staticsymtable,globalsymtable]) then
>>>>           result:=make_mangledname(prefix,owner,typesym.name)
>>>>         else
>>>> result:=make_mangledname(prefix,findunitsymtable(owner),'DEF'+tostr(DefId))
>>>>
>>>>       end;
>>> Somehow I have the feeling that this should be corrected...
> My knowledge of the wokings of the compiler are not detailed enought to
> judge or fix this issue.

I didn't want to imply that you should do it :)

> Shall I report it on the bugtracker?

I don't see a need. It's not a real bug, just not nice... I'll likely 
correct it myself sometime...

>>> Or are nested types also referenced by the definition id?(I had
>>> something on my mind like Unit Type SubType with some seperators("$")
>>> in between)
>> Looking at the code above you could try whether "typesym" of the
>> procvardef is assigned if it is a named one.
> Checking for typesym woks fine for my test and use cases.

Ok, now if you'd be so kind to "revert" the formatting changes to the 
case-block (with exception of the indentation of the whole block) it 
would be nice if you'd open a feature request with your patch and 
preferrably together with one or more test cases (only simple ones with 
as less dependencies as possible, please). I personally am rather sure 
that we'll include it then :)

Regards,
Sven



More information about the fpc-devel mailing list