[fpc-devel] Problem with unit initialization order

[Hans-Peter Diettrich]

Jonas Maebe schrieb:

>>> * I assume
>>> that all the code you added in psystem.pas is with the long term view
>>> of making the parser independent. However, that is a separate project
>>> and not part of removing global variables from the compiler
>>
>> Both are related, since the "stateful" variables are related to 
>> current_module, and that's where the scanner and parser is involved, 
>> somehow.
> 
> That does not answer my remark, but I don't know how to make my point 
> clearer.

After a review of psystem, I found the changes related to the weak setup 
of the nodetype and other classtype variables, in the general and target 
specific units. It's an independent part of my work, that can be undone 
and treated as a separate improvement. The general idea is like this:

Before: In order to avoid references to target specific units, a couple 
of classtype variables have been established in various units. The 
original implementation initializes these variables in the general 
compiler units, together with the related class declarations. Later on 
some values are overridden by CPU specific classes, in CPU specific 
units, what also happens in the unit initialization section. This leads 
to dependencies in the *order* of the used units, as I observed after 
moving unit references between the interface and implementation uses 
clauses, resulting in an broken compiler.

After: This positional dependency of the units in uses clauses can be 
eliminated when the variables are left uninitialized by the general 
units, and instead missing initialization (by target specific units) is 
detected and handled on their first use, here in psystem.registernodes.

The handling of uninitialized variables can be implemented by using 
defaults, as implemented in the NoGlobals branch, or by reporting an 
fatal InternalError indicating that the currently used set of target 
specific units missed to initialize such a variable.


This is only a suggestion, which can be implemented in one of the 
indicated ways, or everything can be left as weak as it is.

DoDi