[fpc-devel] "helper" feature finished

[Sven Barth]

Hello together!

Today I have run the final tests on the helper branch and I'm satisfied 
with their results, thus I'd like you to review and hopefully merge my 
work. The wiki page I have started will be updated as soon as I find the 
time.

Both "class helpers" and "record helpers" are implemented and work as 
Delphi compatible as reasonably possible.

The following differences (that I'm aware of) exist:

* in mode ObjFPC the method modifiers "message", "virtual", "override", 
"final" and "reintroduce" are forbidden as they can't be used in a 
useful way for helpers anyway (they are ignored in mode 
Delphi).("abstract" is rejected in both modes)
* in mode ObjFPC inheritance (and also "inherited") is enabled for 
"record helpers" while it's forbidden for them in mode Delphi (note: 
"inherited" is also needed inside a helper to call a method of the 
extended type when a method with the same name (and maybe parameters) 
exists in the helper as well)
* Delphi does not respect the visibility of nested helpers, FPC does 
(this was reported at Embarcadero's code central)
* the biggest difference between Delphi and FPC is in the RTTI: while in 
Delphi helpers are "magically enhanced" descendants of a 
"TClassHelperBase" class (which in turn inherits from 
"TInterfacedObject"), helpers are a type of their own in FPC (are such 
types called "first class types"?). Thus they have their own RTTI type 
(tkHelper) and their own type data which contains the parent helper 
(like Delphi) and the extended type (Delphi does not provide this).
I have decided to follow this route as I was already too advanced to 
change my implementation and I also didn't want to carry around a 
reference to a class that's only needed to satisfy Delphi compatibilty 
in a corner case.

Some notes regarding the tests:
* two of the general helper tests (thlp*) fail because of missing 
generic features (generic methods and generic constraints) - to be more 
precise: one fails because generic methods are missing and should not 
fail, the other one fails because constraints are missing, butit should 
fail anyway...
* three record helper tests (trhlp*) fail, because nested types are not 
supported by (advanced) records (two should fail nevertheless, because 
they try to access (strict) private helpers, the third should succeed)
* three more record helper tests fail, because the abbreviated syntax to 
access default properties is not supported

I'll report bugs for the last two points as those work in Delphi.

Regarding performance:
For projects that don't use helper types (like currently all code 
provided by FPC) there isn't much speed difference, because
1. I check whether a symtable contains a helper at all (using the new 
symtable options) before searching through it when it's pushed on the 
symtable stack
2. I check whether the current module contains helped types at all

Thus there isn't that much speed difference between the modified 
compiler and an unmodified trunk one. It will only become noticeable 
when a project contains helpers. Maybe then a possible reduction of 
performance could be achieved by caching the mangled name of a type 
(which is used as lookup key) instead of generating it each time that 
type is accessed (I didn't want to do such a change during the 
implementation of the helper feature).

Regards,
Sven