[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