I could, but I attached a patch first. Before I commit this to a branch I want to know that I'm on the right track. Could you and/or others have a look at the patch?

I'm especially interested if things are done in the right units, and if the code in ptypes.pas is acceptable.

Attached are the patch and a simple test-program.

First an example what class-attributes are:

type
  TMyObject = class
  published
    [TAttributeClassName('param1','param2')]
    property AProperty;
  end;

When you request the class-property that belongs to the property AProperty, then you get an instance of the TAttributeClassName class which is constructed by calling it's constructor with the supplied parameters. (In this case 'param1' and 'param2')

How I implemented this:
For each attribute a function is generated that returns a class-instance of the attribute. This function is generated in ptypes by creating a tcgprocinfo. All the necessary nodes are added to it and then tcgprocinfo.generate_code is executed.

In the rtti-info (ppropinfo) the address of this function is stored so that it is possible to read those attributes.

If I'm on the right track I'll add a branch with this patch and work from there. Some issues:

- In Delphi an attribute-class has to be defined as a TCustomAttribute. That way it's also clear which constructor has to be called. For now, it calls the first constructor it can find.

- The rtti-info is now stored inside PPropInfo, I don't think that this is how Delphi does it, also because in Delphi you need the 'rtti' unit to get this information. I've added it to typinfo and later on a 'rtti' unit could be written as a wrapper around typinfo.

- When we add more rtti-information to types we need a way to specify what to generate and what not and where to store it. Especially because the rtti-info will grow.

- No error is generated when you define an attribute for something else then a property.

- The attribute-definition is stored in the .ppu, but that's not really needed. Since at compile-time this information is never used by another unit. I used it for debugging though (with ppudump) A side-effect is that when an attribute is changed, a recompilation of the unit is forced. Do we want that? (For now only the attribute-type is stored in the ppu, not the parameters)

Joost.

Some small remarks that I noticed:

* please call your "generate_rttiattribute_procs" after the "generate_specialization_procs" as methods of generics could force the specialization of a class that is not yet specialized, but that carries attributes
* maybe it's better not to generate attribute data for generics, I don't know... (simply check for "df_generic in ttypesym(p).typedef.defoptions" in generate_rttiattribute_procs_classes)
* in generate_rttiattribute_procs_properties you also need to handle nested classes
* you should increase the PPU version in ppu.pas as you added a new field
* you might want to call me blind, but where did you add the field rtti_attributesdef to, to which you assign the current_rttiattributedef? (can it be that you forgot that in the patch?)

And two questions:
* does the usage of attributes with methods/fields depend on the availability of the extended RTTI?
* can attributes also be used with records in Delphi? (as they can now carry properties as well)

Regards,
Sven

Ok, I'll change that.

* maybe it's better not to generate attribute data for generics, I don't know... (simply check for "df_generic in ttypesym(p).typedef.defoptions" in generate_rttiattribute_procs_classes)

I'll will look what Delphi does. In principle i don't a reason why it shouldn't work.

* in generate_rttiattribute_procs_properties you also need to handle nested classes

Ah yes, offcourse. I will also look at the 'normal' rtti generation, I copied the code from there. Maybe that there is no rtti information generated for nested classes at all at this moment.

* you might want to call me blind, but where did you add the field rtti_attributesdef to, to which you assign the current_rttiattributedef? (can it be that you forgot that in the patch?)

See the second change in pdecobj. (In procedure truct_property_dec)

And two questions: * does the usage of attributes with methods/fields depend on the availability of the extended RTTI?

Yes. Without extended RTTI you can not get a list of method/fields at runtime. So where should the attributes be bound to?

* can attributes also be used with records in Delphi? (as they can now carry properties as well)

I don't know. Do we support rtti on records? I think this is also a part of what Delphi calls 'extended rtti'.

Joost

Thanks.

I don't know whether you can query the RTTI of a generic class at all (note: I talk about the generic itself, not a specialization of it); also the RTTI generation in FPC is already disabled for generics (as well as the VMT generation).

If so this should be fixed AFAIK.

Yes, I see the change in pdecobj, but I'm missing the change in the class where "p" is an instance of. Ah... now I found what I was looking for: the change in symsym.pas... ^^

Ok... then it's indeed better to wait with attributes for other class members besides properties until the extended RTTI is added as well.

I don't know either. I just wanted to ask out of completeness ^^

Otherwise from the perspective of a "junior compiler developer" the patch looks ok. :) [I haven't tested it yet though]

Regards,
Sven