[fpc-devel] Error: Procedure/Function declared with call option NOSTACKFRAME but without ASSEMBLER

[Martin Frb]

Ok, maybe I lost the point in verbosity.

The following type
    type  a=procedure foo;
gives the error
     project1.lpr(2,19) Fatal: Syntax error, ";" expected but 
"identifier FOO" found

In a type declaration, the procedure can not have a name, and "foo" is 
not a valid modifier here (cdecl would be and can be given).

But then
     type  a=procedure NoStackFrame ;
gives
    project1.lpr(3,1) Error: Procedure/Function declared with call 
option NOSTACKFRAME but without ASSEMBLER

Though I can not specify
     type  a=procedure assembler;
because it also gives
    project1.lpr(7,33) Fatal: Syntax error, ";" expected but "identifier 
ASSEMBLER" found

I.e. assembler seems not to be relevant for the type declaration. It can 
only be given when I actually declare a procedure.

It also wont work as
     type  a=procedure assembler NoStackFrame ;
     type  a=procedure NoStackFrame assembler;


So why does the compiler interpret NoStackFrame in the type declaration, 
when it does not do that for other non-relevant modifiers (like assembler)?


Just curious...

On 20/03/2025 20:23, Marco van de Voort via fpc-devel wrote:
>
> Op 20-3-2025 om 20:09 schreef Martin Frb via fpc-devel:
>> It is possible to declare a type for a cdecl function like
>> type  a=procedure cdecl;
>>
>> But, not for "assembler" which makes sense, because its not a calling 
>> convention. Same should likely be the case for NoStackframe.
>
> Roughly yes. Basically a procedure variable is a contract which should 
> give the calling situation enough information to call the said function.
>
>
>> But
>>
>> program Project1;
>> type  a=procedure {assembler} NoStackFrame ;
>> begin
>> end.
>>
> assembler is a comment?
>
>
>> gives a different error?
>
> Which error do you mean? Not to be facetious, just that errors might 
> depend on architecture.
>
>
>> Should it?
>>
> The bar is twofold, the first, as said,  being that the calling side 
> must have enough information to call the result in all circumstances 
> (read: on all targets), and the second , minor one, if that if there 
> is an exception for parameterless functions, if it is worth to 
> implement an exception.
>
>
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel