Gale Paeper wrote:
It looks like a bug to me.
Frank, I believe the problem is in the optional_unit_implementation production in the empty alternative. I think just adding implicit_module_constructor and implicit_module_destructor functions calls in the code block containing the "CHK_DIALECT" macro would fix the problem.
Indeed. (Our mails just crossed each other. :-)
A larger issue, though, is why are "pure" interface units (and modules) included in the initialization and finialization call chains. By pure, I mean they are strictly interface declarations for external code which isn't going to be in the Pascal language initialization and finalization context. These are what ISO 10206 would refer to as an externaal interface. Paragraph 6.1.5, Interface-directives has a note which covers this:
"NOTE --- A processor may provide, as an extension, the interface-directive external, which is used to specify that the module-block corresponding to the module-heading containing the interface-directive is in some form other than an Extended Pascal module-block (e.g., it is implemented in some other language). When providing such an extension, a processor should enforce the rules of Extended Pascal pertaining to type compatibility."
Well, it "may provide", but doesn't have to. ;-) In my experience it's often useful to have a lot of external declarations and some Pascal ones, e.g. to make some interfaces easier to use from Pascal or add some functionality. Examples of this are the GMP and RegEx units that come with GPC, the two Pascal units in the GRX library, or the MySQL unit by Eike Lange.
The Mac OS X interface units Peter and others are working on is exactly the case the note is describing. There are no corresponding Pascal module-block or unit-implemenation-part for the interfaces.
Perhaps it will turn out useful to add some. :-)
Based on quick look, I think you should be able to handle purely external interfaces in the same manner as the standard interfaces are handled in creation of the call chain from import/uses. If an import/uses of a purely external interface is encountered, just skip adding it to the intializer chain which would eliminate the necessity for generating the hidden functions for "pure" external interfaces.
It might be possible in this case (though not in cases where `implementation' is given, but no explicit initializer since there are problems with circulare references). You'll have to check whether the unit uses any other units with intializers or contains auto-initialized variables (because then it does need an initializer).
If you (or someone else) wants to do it, just go ahead. I have more important things to work on (since this is neither a bug, nor a missing feature, only a (very minor) performance issue, it's very low on my priorities) ...
Frank