[fpc-devel] RTTI for ProcVar types
Sven Barth
pascaldragon at googlemail.com
Mon Mar 25 10:01:41 CET 2013
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...
> 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.
>> Also if you should do a bug report please reformat your patch first,
>> so that it adheres to the compiler's format style (and don't change
>> the formatting of other code like the one in the case except for
>> overall indentation). E.g. for the above code from your patch
> Is there some template to use with code tools oder some formatter you
> use.(For this I think I can manage manually but if further issues
> arrise. It would be better to know if there an easier way to do this^^)
>
No, there is none. Also there isn't a completely fixed formatting (yet),
because some parts of the compiler are from times where there wasn't a
specific formatting yet. I myself am doing the formatting manually,
because for my own projects I prefer a different one (that's also why
I've reported this Lazarus feature request:
http://bugs.freepascal.org/view.php?id=18517 )
Regards,
Sven
More information about the fpc-devel
mailing list