Hi everyone,
So I'm making progress with my pure function implementation, or something passing as an early alpha prototype.  I do have a question though... when the "firstpass" routines are called, have all the procedures been compiled into nodes yet? I'm still trying to work out the best time to evaluate function purity, partly due to constructs such as this:

 interface
 function PureFunc1(Input: Integer): Boolean;
 function PureFunc2(Input: Integer): Boolean;
 implementation
 function PureFunc1(Input: Integer): Boolean; pure;
 begin
   Result := PureFunc2(Input * Input); { "pure" directive for PureFunc2
hasn't been seen yet }
 end;
 function PureFunc2(Input: Integer): Boolean; pure;
 begin  { Do something complicated but deterministic! }
 end;

****

I could probably find the answer after some long research, but I'm trying to avoid wasting time unnecessarily.  I would guess that the evaluation should occur at a similar time to when inline functions are expanded, where they are fully-defined and known to be inlinable.

Gareth aka. Kit

J. Gareth Moreton schrieb am Mi., 8. Aug. 2018,
23:45:

First of such modifiers should only be allowed in the interface section, not the implementation section as they would essentially be a change of the routine's signature (doesn't matter that it isn't part of the routine's mangled name) and thus a change of the unit's interface which in turn would require a recompilation of units using that unit.

To your question itself: once a non-nested routine body is parsed it's code is generated which includes both the first and second pass. For nested routines the same is done once the outermost routine as been parsed (but before that one's first pass).

Regards,
Sven

Gareth sent me the following two mails in private, but they were ment for the list:

I hadn't thought that I need to explain that, but apparantly you haven't yet reached that far in your research of the compiler, so:
- of course I only mean that it's an interface-only modifier if there *is* an interface section; routines that are - inside a unit - only declared inside the implementation section are obviously exempt from this (thus also for the program file)
- again I wrote that I don't mean that "pure" modifies the parameters, but it modifies the meta data (most importantly checksum) of the interface section when you add a modifier flag inside the implementation section. The compiler first handles the interface sections of units and might then compile interface sections or even implementation sections of other units depending on the dependencies between the units. If a flag only appears in the implementation section than this messes up this whole thing as the other units would need to be recompiled. This is already a mess with "inline" so we don't need to do that with "pure" as well, especially as we don't need to be Delphi compatible here.
- yes, it is correct that the compiler's capability to inline depends on the order of the routine definitions. The compiler generates the code routine by routine so if the routine's body has not yet been encountered then it can't be inlined. (When using generic specializations it triggeres the generation of the specialized routine bodies before generating the routine to avoid "inline" not working for generics) For "pure" we can even go so far as to say that a routine body *must* be available to be able to call it inside another "pure" routine. Everything else would be an error.

I hope this clears things up a bit.

Regards,
Sven