[fpc-devel] Debug compiler

Sven Barth pascaldragon at googlemail.com
Mon Nov 2 20:24:19 CET 2015

On 01.11.2015 06:26, Ondrej Pokorny wrote:
> + I was wrong about the need to use "tenumeratornode". Actually you can
> use "tcallnode" and get *pd* and *expr* for
> *create_enumerator_for_in_loop* from its properties in function
> *create_for_in_loop*:
> expr:=tcallnode(expr).methodpointer;
> pd:=tprocdef(tcallnode(expr).symtableprocentry.ProcdefList[xyz]); //
> (you have to find the compatible overload)
> (If you don't know what I mean I can send you the code. It's working
> like a charm.)

I personally think it's better to use tcallnode than to introduce 
another node. I know there is already a parser only node, namely 
specializen (added by me), but that node /really/ simplifies things 
unlike that enumerator node.

> The only thing we need is a new flag/whatever so that
> *create_for_in_loop* knows that "tcallnode(expr)" contains an enumerator
> function. tnode.flags seems to be full :( Do you have any suggestions?
> If we sort this out, 2 more arguments against it are nil :)

I see three possibilities to avoid the addition of a global flag:
- simply always return the enumerator function if no arguments are given 
for an indexed array (pro: easy to implement; con: will bite us once we 
add another functionality that works on the array property as a whole)
- always return the enumerator, but add checks everywhere except the 
for-in parsing against the enumerator (maybe for this case the 
enumerator node would be an advantage) (pro: enumerator will only work 
in for-in; con: every expression handling code needs to maintain that code)
- extend comp_expr by another boolean parameter (which is set in 
for_in_loop_create) and pass that down to factor (even better: convert 
the boolean parameters of comp_expr, sub_expr and factor to a set, would 
be cleaner anyway, IMHO) (pro: the state is only maintained locally and 
new flags can be added easily; con: a greater change in the compiler, 
though that would be a onetime thing)

I personally would prefer point three. Maybe I'd even manage to do that 
change during this week (I have vacation after all, so I should have 
time ^^) and then you can redo your patch based on this.


More information about the fpc-devel mailing list