Inline across units does not inline

[AlanTheBeast]

I have a very brief pair of procedures:

Code: Pascal  [Select][+][-]

1. Procedure MarkWin;  inline;
2. begin
3.      ConsoleWindowGetXY(Con3,Wix,Wiy);
4.      WiCo := ConsolewindowGetForeColor(Con3);
5. end;
6. Procedure RestWin;  inline;
7. begin
8.      ConsoleWindowSetXY(Con3,Wix,Wiy);
9.      ConsolewindowSetForeColor(Con3,WiCo);
10. end;

Which only inline in the unit in which they are declared.  The procedures are exported via interface, but other units that use them result in the not inlined message during build.

I've kludged this by repeating the procedures (but not the vars) in the bodies of the other units, but question if this is normal?

I suppose it makes sense as the compiling units only see the declaration for the procedure, not its body.

Just answered my own question perhaps...

[Martin_fr]

Is the "inline" modifier also present in the interface section?

Because, its required so it can be used by other units.

[AlanTheBeast]

Is the "inline" modifier also present in the interface section?

Because, its required so it can be used by other units.

I believe so, but I'll re-verify when I get back.

I misunderstood your question on first read, yes, the interface declarations are exact copies of procedure decl.

I really believe it's simply because the actual code is out of scope when the compiler is compiling a different unit - so it would know "what" to put inline.

[Martin_fr]

Also, you are using "-Si" ? (its on by default, but...)

No:
-Si-
{$INLINE off}

Yes, those should be obvious. But sometimes ...

Further: Are there circular references between those units (direct, or through a bigger circle)? Because then the order in which the implementation parts are compiled comes into play...

And even further, any clues in form of warnings or hints during compile? Maybe you are using something for which inlining is not implemented (at least not cross unit).

[AlanTheBeast]

Also, you are using "-Si" ? (its on by default, but...)

No:
-Si-
{$INLINE off}

Yes, those should be obvious. But sometimes ...

Further: Are there circular references between those units (direct, or through a bigger circle)? Because then the order in which the implementation parts are compiled comes into play...

And even further, any clues in form of warnings or hints during compile? Maybe you are using something for which inlining is not implemented (at least not cross unit).

I wasn't using anything.  So the inlines were succeeding in the units where the procedures are coded, just not in the other units.
I'll re-verify when I get back for the exact order of things.
Also, this is ARM/Ultibo which may have some bearing on the issue.

No circular references that I can imagine, but I'll re-look.  The usage of this pair is:

SpinLock(zzz);
Markwin
A few lines of code with no calls outside other than system (write, etc.).
RestWin
SpinUnLock(zzz);

Indeed, I may add the SpinLock to the one and SpinUnLock to the other.

[PascalDragon]

I have a very brief pair of procedures:

Code: Pascal  [Select][+][-]

1. Procedure MarkWin;  inline;
2. begin
3.      ConsoleWindowGetXY(Con3,Wix,Wiy);
4.      WiCo := ConsolewindowGetForeColor(Con3);
5. end;
6. Procedure RestWin;  inline;
7. begin
8.      ConsoleWindowSetXY(Con3,Wix,Wiy);
9.      ConsolewindowSetForeColor(Con3,WiCo);
10. end;

Which only inline in the unit in which they are declared.  The procedures are exported via interface, but other units that use them result in the not inlined message during build.

Are the ConsoleWindow* functions declared only in the current unit in the implementation section? What FPC version are you using? Can you provide a full example that shows this?