The parameter manager converts from the internal compiler representation of
a parameter's location to an RTTI representation. As the general implementation
more or less directly uses the compiler structures for this a platform specific
parameter manager may override this functionality in case some parameter
information changed in a non-backwards compatible way.
The RTTI parameter location has a layout that allows for an easy enumeration
as the size is fixed for all locations. Additionally there are properties that
allow for easy access to the information stored in them.
git-svn-id: trunk@35250 -
Commit message of patch:
+ New field TotalFieldCount for TTypeData
* Mark ManagedFldCount as deprecated
* Adjusted test trtti12.pp
git-svn-id: trunk@35180 -
* have tkInt64 and tkQWord entries also contain the OrdType field (basically the compiler can now use the same function to generate them only with different type kinds)
+ added test
git-svn-id: trunk@35135 -
* adjusted test trtti10.pp due to renamed RecInitTable field
Original commit message:
Public interface for init table for records in TypInfo:
* Rename RecInitTable to RecInitInfo (because it is special kind of PTypeInfo for init table of record). Has more sense in practical usage.
+ New structure TRecInitData (and related PRecInitData) to handle data for (init) type info for records (aka init table)
+ New structure TInitManagedField and pointer type PInitManagedField (for init table)
+ Special helper property RecInitData to get PRecInitData for tkRecord
+ test attached
git-svn-id: trunk@35134 -
- indentation in ncgrtti.pas
- fewer ifdefs in rtti.inc
- InitTable/Terminator field as first field to avoid padding on targets that require proper alignment and have SizeOf(Pointer) > 4
Original message by Maciej Izak:
Breaking change for rtti layout for record rtti. Init table
is always accessible from regular rtti. Rtti table contains indirect
reference to init table, additionally init table contains nil-terminator (for
rtl purposes - the only way to determine kind of info : init or rtti). Pros:
* will be possible to create more Delphi compatible code for RTTI, finally end-user can access to *real* managed fields of records (some work on TypInfo.pp is still required but is not necessary).
* important step forward for management operators (anyway this commit is not directly related to management operators)
* much more optimal memory allocation/initialization/finalization for records created/destroyed by InitializeArray/FinalizeArray, for example:
type
TBar = record
f1,f2,f3,f4,f5,f6,f7,f8,f9: byte;
s: string;
end;
previously:
GetMem(PB, SizeOf(TBar));
InitializeArray(PB, TypeInfo(TBar), 1); // FPC_INITIALIZE was executed 10 times
now:
GetMem(PB, SizeOf(TBar));
InitializeArray(PB, TypeInfo(TBar), 1); // FPC_INITIALIZE is executed just once
+ test attached
git-svn-id: trunk@35125 -
Merged revision(s) 28239-28289 from branches/svenbarth/packages:
Provide the possiblity to switch between the direct and indirect RTTI symbols.
ncgrtti.pas, TRTTIWriter:
+ get_rtti_label, get_rtti_label_ord2str & get_rtti_label_str2ord: add new "indirect" parameter and pass that along to rtti_mangledname
hlcgobj.pas, thlcgobj:
* g_incrrefcount, g_initialize, g_finalize, g_array_rtti_helper: for now pass along False to get_rtti_label()
ncgvmt.pas, TVMTWriter:
* writevmt: for now pass along False to get_rtti_label()
ncgld.pas, tcgrttinode:
* pass_generate_code: for now pass along False to the get_rtti_label*() methods
........
Provide possibility to select between using a direct and an indirect RTTI reference. This way the references can be changed for selected cases.
ncgrtti, TRTTIWriter:
* ref_rtti: new "indirect" parameter that's relayed to rtti_mangledname()
* write_rtti_reference: new "indirect" paramater that's relayed to ref_rtti()
........
Switch properties to use the indirect type information without breaking backwards compatiblity. :)
compiler/ncgrtti.pas, TRTTIWriter:
* published_properties_write_rtti_data: use the indirect reference, not the direct one
rtl/objpas/typinfo.pp:
* to allow compilation with both 2.6.x and 2.7.1 and too avoid too many ifdefs at least in the declarations we define a macro TypeInfoPtr which is either PTypeInfo (2.6.x) or PPTypeInfo (2.7.1 and newer)
* TPropInfo: rename PropType to PropTypeRef and change type to TypeInfoPtr
+ TPropInfo: add a new property PropType which returns a PTypeInfo out of the PropTypeRef depending on the compiler version
........
Switch further simple types (sets, enums, class references, pointers) to indirect type information (again without breaking backwards compatibility).
compiler/ncgrtti.pas, TRTTIWriter.write_rtti_data:
* enumdef_rtti, setdef_rtti, classrefdef_rtti & pointerdef_rtti: write an indirect RTTI reference
rtl/objpas/typinfo.pp, TTypeData:
* rename BaseType to BaseTypeRef, CompType to CompTypeRef, InstanceType to InstanceTypeRef and RefType to RefTypeRef and change their type to TypeInfoPtr
+ add properties BaseType, CompType, InstanceType & RefType which return a PTypeInfo out of the corresponding *Ref field depending on the compiler version
........
Switch class and interface parent as well as extended type to indirect type information
compiler/ncgrtti.pas, TRTTIWriter:
* write_rtti_data.objectdef_rtti.objectdef_rtti_class_full: use indirect reference for class parent and extended type
* write_rtti_data.objectdef_rtti.objectdef_rtti_interface_full: use indirect reference for interface parent
rtl/objpas/typinfo.pp, TTypeData:
+ add new method DerefTypeInfoPtr which returns Nil if the indirect reference is Nil and otherwise returns the dereferences indirect reference (for 2.6.x the direct reference is returned as is)
* rename ParentInfo to ParentInfoRef, HelperParent to HelperParentRef, ExtendedInfo to ExtendedInfoRef, IntfParent ot IntfParentRef and RawIntfParent to RawIntfParentRef and change their type to TypeInfoPtr
+ introduce ParentInfo, HelperParent, ExtendedInfo, IntfParent and RawIntfParent properties that return a PTypeInfo and use the new DerefTypeInfoPtr to return the correct type info value
* change the other newly introduced properties of TTypeData to use DerefTypeInfoPtr as well to be on the safe side
........
Switch record/object fields to indirect type information references.
compiler/ncgrtti.pas, TRTTIWriter.fields_write_rtti_data:
* use the indirect reference for the object parent type
* use the indirect reference for the field type
rtl/inc/rtti.inc:
* TRecordElement: change TypeInfo to PPointer for 2.7.1 and newer
* RecordRTTI: correctly dereference the element type for 2.7.1 and newer
* fpc_copy: correctly reference the element type for 2.7.1 and newer
........
Switch static arrays to indirect RTTI reference.
compiler/ncgrtti.pas, TRTTIWriter.write_rtti_data:
* arraydef_rtti: write the dimension types and the final field type as indirect references
rtl/inc/rtti.inc:
* TArrayInfo: switch ElInfo to PPointer for 2.7.1+
* ArrayRTTI & fpc_copy: correctly dereference ElInfo for 2.7.1+
rtl/objpas/typinfo.pp, TArrayTypeData:
* switch ElType and Dims to PPTypeInfo; no backwards compatibility needed here as TArrayTypeData was added in 2.7.1 only
tests/test/trtti8.pp: fix test
........
Switch dynamic arrays to indirect RTTI references.
compiler/ncgrtti.pas, TRTTIWriter.write_rtti_data.arraydef_rtti:
* write indirect references for the two element entries
rtl/inc/dynarr.inc:
* tdynarraytypedata: change elType2 to PPointer for 2.7.1+
* fpc_dynarray_clear, fpc_dynarray_setlength & fpc_dynarray_copy: correctly dereference elType2 for 2.7.1+
rtl/objpas/typinfo.pp, TTypeData:
* rename elType and elType2 to elTypeRef and elType2Ref respectively and change type to TypeInfoPtr
* add properties elType and elType2 which return PTypeInfo by dereferencing elTypeRef and elType2Ref respecively correctly
* remove a few stray "inline" directives in the implementation
........
Switch procedure parameters and result type to indirect RTTI references.
compiler/ncgrtti.pas, TRTTIWriter.write_rtti_data.procvardef_rtti:
* write_procedure_param: use indirect RTTI reference
* write result info for both methods and procvars as indirect RTTI reference
* write parameters for procvars as indirect RTTI reference
rtl/objpas/typinfo.pp:
* TProcedureParam: change type of ParamType to PPTypeInfo (no backwards compatiblity needed here; was added for 2.7.1)
* TProcedureSignature: change type of RseultType to PPTypeInfo (no backwards compatibility needed here; was added for 2.7.1)
* TTypeData: remark in the comments of tkMethod that ResultTypeRef and ParamTypeRefs are of type PPTypeInfo and not PTypeInfo
tests/test/trtti9.pp:
* fix test
........
Remove no longer needed "indirect" parameter for TRTTIWriter methods.
ncgrtti.pas, TRTTIWriter:
- ref_rtti & write_rtti_reference: remove "indirect" parameter
* ref_rtti: call rtti_mangledname with "indirect" always set to "true"
- remove "true" parameter on callsites of write_rtti_reference & ref_rtti
........
git-svn-id: trunk@33944 -
(still not sure if it's a good idea, but trying, at least, is harmless - we
can always rollback to integer being equal to longint)
git-svn-id: trunk@26966 -
* typinfo.pp: the newly introduced records were added into {$PACKRECORDS 1} area of effect, which effectively made all records packed, entirely defeating FPC_REQUIRES_PROPER_ALIGNMENT purpose.
* added alignment between TProcedureParam records, adjusted TProcedureSignature.GetParam() appropriately.
* ncgrtti.pas: added two missing alignments and removed a redundant one.
* tests/test/trtti9.pp: modified to use TProcedureSignature.GetParam() and endian-independent check for parameter flags.
git-svn-id: trunk@24562 -
- TotalSize of all array dimensions instead of first dimension size
- Element type of last array dimension
- dimension information
rtl:
- adopt array initialization/finalization/copy for the new tkArray RTTI
- add Delphi compatible TArrayTypeData member for typinfo.TTypeData structure
tests:
- add a test which checks RTTI information for 2 dimension array
git-svn-id: trunk@24458 -
- write pint instead of 32 bit for record field offset (compiler uses aintsize = pint in TRecordDef), use PtrInt in RTL for record reading
- add tkRecord to TTypeData (field and type names are taken from Delphi help)
- add tkProcedure as alias to tkProcVar
git-svn-id: trunk@24424 -
* compiler/ncgrtti.pas:
- objectdef_rtti_class_full:
- don't write the VMT data for helpers
- write the typeinfo of the extended type (something that Delphi does definitely not support :P )
- objectdef_rtti: write the new type kind for helpers instead that of classes
* compiler/symconst.pas: introduce new type kind constant "tkHelper" before "tkFile" (what is that used for btw?)
* rtl/inc/system.inc: add the constant here as well (why wasn't tkUChar added here?)
* objpas/typinfo.pp:
- add tkHelper to the TTypeKind enum (but here tkUChar was added?!)
- extend the TTypeData record with the data of helpers
git-svn-id: branches/svenbarth/classhelpers@17240 -
* left old cpu-specific set helper code under ifdef FPC_OLD_BIGENDIAN_SETS
in case someone wants to write new assembler set helpers (although most
of them should be optimally generated by the compiler already if
http://wiki.freepascal.org/FPC_HowToDo#Bit.28field.29_getting.2Fsetting_primitives
are optimally implemented)
git-svn-id: trunk@13582 -
* varsets ({$packset x}) are now supported on big endian targets
* gdb now displays sets properly on big endian systems
* cleanup of generic set code (in, include/exclude, helpers), all
based on "bitpacked array[] of 0..1" now
* there are no helpers available yet to convert sets from the old to
the new format, because the set format will change again slightly
in the near future (so that e.g. a set of 24..31 will be stored in
1 byte), and creating two classes of set conversion helpers would
confuse things (i.e., it's not recommended to use trunk currently for
programs which load sets stored to disk by big endian programs compiled
by previous FPC versions)
* cross-endian compiling has been tested and still works, but one case
is not supported: compiling a compiler for a different endianess
using a starting compiler from before the current revision (so first
cycle natively, and then use the newly created compiler to create a
cross-compiler)
git-svn-id: trunk@7395 -
