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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
