[fpc-devel] Debug compiler

Jonas Maebe jonas.maebe at elis.ugent.be
Sat Oct 31 12:06:47 CET 2015


On 31/10/15 11:33, Ondrej Pokorny wrote:
> Yes, indeed. It's always good to know that a patch will at least be
> considered for including into the trunk before taking the step and
> trying to write one. Otherwise it's wasted time ;)
>
> Thanks for your tips! I uploaded a patch and commented on the issue
> report: http://bugs.freepascal.org/view.php?id=28820

Independent of whether it will be integrated, there are definitely a 
number things that should be changed first:
* don't use the "is" operator unless there is absolutely no other way to 
achieve the same effect. In the compiler, every node has a "nodetype" 
field that can be used to determine the kind instead (which is much 
faster than "is"
* I'm not sure such a "virtual node" is the best approach. I don't think 
we have that anywhere else in the compiler, so unless there is no 
cleaner way, we shouldn't introduce this concept (if some nodes are used 
differently from other nodes --other than the special error node--, then 
maintenance and reasoning becomes harder)
* don't add extra (semi-)global variables such as the 
tscannerfile.inforin field unless there is absolutely no other way to 
achieve the same effect. It's usually a quick hack, and there are way 
too many of those in the compiler already (I've removed a number of them 
over the years, but there are plenty left)
* like for all other node types, create a "tenumeratornodeclass = tclass 
of tenumeratornode" type, a "cenumeratornode: tenumeratornodeclass = 
tenumerator;" global variable and always use cenumeratornode.create() 
(so that the node class can be overridden by an architecture-specific 
class if necessary)
* it seems you have a memory leak (the tenumeratornode doesn't seem to 
be freed anywhere)

There may be more issues, but these are the ones that jump out at first 
sight.


Jonas



More information about the fpc-devel mailing list