[fpc-devel] RTTI for ProcVar types

[Sven Barth]

On 21.03.2013 15:53, Steve Hildebrandt wrote:
> Am 21.03.2013 11:51, schrieb Sven Barth:
>> Out of curiosity: Why did you add this?
> To implement a less "hacky" way of generic method invokation.
> Supporting several calling conventions I can call a method based on the
> address and an array of const as parameters.
> Without RTTI there would've been a need for hard coded meta information,
> wich is error prone and rather time consuming.
> Since tkMethod supports RTTI any method contained in a record, class,
> object would work without additional meta information.

Out of interest: do you support multiple platforms? Maybe if you want to 
provide your code under modified LGPL we could use it once we have the 
RTTI.TValue type and the extended RTTI to support RTTI.Invoke.

> I'm currently using this to call pascal procedures and use pascal
> classes in LUA.
>> Without you showing what you changed we can not help much...
> typinfo.pp :
> tkMethod, tkProcVar: // simply added tkProcVar here
>                (MethodKind : TMethodKind;
>                 ParamCount : Byte;
>                 ParamList : array[0..1023] of Char
> ncgrtti.pas:(Line 690)
> procedure procvardef_rtti(def:tprocvardef);
> ...
> begin
>    { write method id and name }
>    if po_methodpointer in def.procoptions
>      then write_header(def,tkMethod)
>      else write_header(def,tkProcVar);
>    maybe_write_align;
>    ...
>
> So that RTTI generation for tkProcVar and tkMethod would only
> differentiate in the TTypeKind field.

I can reproduce your problem, but I don't have a solution. At least it 
is enough to only use that unit, so you could copy the unit locally and 
comment everything until the problem disappears. This way you could 
pinpoint what construct the problem is and then try to fix the compiler. 
And if it then works without further problems we could add this to trunk.

Regards,
Sven