I still get errors on deallocation in fpdoc from time to time.

The most recent one is related to TPasFunctionType.

I searched a bit, and since the type is not used that much, I suspect TPasTreeContainer.CreateFunctionType.

Since in both cases the resultparent is an already used reference, shouldn't it be increfed ?

Probably.

Till you told me, I wasn't even aware that there was a refcounting mechanism. I see no reason why there should be one, so I'd be in favour of removing it alltogether.

Michael.

In our previous episode, Michael Van Canneyt said:

Then you need some global list to add them to. (to be able to deallocate). It might be the various TPasModule sections already double as something like this, but that has to be validated.

Dmitry, what do you think?

Why ?

It might be the various TPasModule sections already double as something like this, but that has to be validated.

Each element should deallocate it's "children".
Since an element tree is always a strict tree, this is unambiguous. Refcounting is not 'm not in favour of a global list and a 'garbage collection' style of memory management. It makes manipulating the tree a pain.

This will take some reworking, apparently (each destructor must be filled with code to deallocate children). For the time being, try the incref.

Michael.

In our previous episode, Michael Van Canneyt said:

I don't really see this, since in many of passrc's routines objects are created if they cannot be found? This means that there is a chance that such object has no other refernece than the one returned. E.g. when searched for a reference that is not strictly a child like ancestor.

That would need to be refactored too then.

If ref-counting mechanism is already implemented, i'd prefer to keep and debug it.

thanks,
dmitry

dmitry boyarintsev wrote

If ref-counting mechanism is already implemented, i'd prefer to keep and debug it.

And why do you want this ? refcounting is always a pain, and should be avoided when possible.

Michael.

Michael Van Canneyt wrote

And why do you want this ? refcounting is always a pain, and should be avoided when possible.

Rewriting code might produce even more bugs. I prefer to make as less changes as possible.

thanks,
dmitry

We would not be rewriting the parser; merely the TPasElement nodes.

I'll do it myself, this is not a problem.

Michael.

Michael Van Canneyt wrote

We would not be rewriting the parser; merely the TPasElement nodes. I'll do it myself, this is not a problem.

Ok then. No more refcounting.

So TPasExpr classes doesn't require changes. Currently they free sub expressions instead of releasing them.

thanks,
dmitry