Proposition — new modifier to force compiler to inline or throw warning/error

[furious programming]

Yes, there is. However, it has the misleading name {$include} and requires some changes (in comparison to simply appending a keyword to the routine declaration).

On the one hand, this solution works, but on the other hand, it is so stupid and impractical that no one in their right mind would write code this way. Especially in the case of a large project that may have hundreds/thousands of subroutines to be inlined. This should be done by the compiler, not by a human — the developer should only instruct the FPC what to do. However, there is no such possibility and hence my proposal.

[MarkMLl]

On the one hand, this solution works, but on the other hand, it is so stupid and impractical that no one in their right mind would write code this way. Especially in the case of a large project that may have hundreds/thousands of subroutines to be inlined. This should be done by the compiler, not by a human — the developer should only instruct the FPC what to do. However, there is no such possibility and hence my proposal.

A multiline macro might be more practical. I've found this sort of thing useful in the past

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

1. {$ifdef ERROR2 }
2. {$define EXIT_ERROR:= begin
3.                         if fatal then begin
4.                           Flush(Output);
5.                           ErrorLine;
6.                           WriteLn(ErrOutput, '*** Error: in ', PeekRule(), ': unable to parse ', PoppedRule());
7.                           Flush(ErrOutput)
8.                         end;
9.                         exit(result)
10.                       end }
11. {$else         }
12. {$define EXIT_ERROR:= exit }
13. {$endif ERROR2 }
14.  

Usual comment of course about the lack of support for parameters.

MarkMLl

[furious programming]

After thinking about it for a while, I think my proposal is incorrect, may be harmful and prevent the code from being compiled. I didn't take into account one key case — when a given function is marked as inlined and some calls may be inlined and some may not. If the compiler were to stop compilation when it is not technically possible to inline, it would be very burdensome and instead of having inline at least some of the calls, you would have to remove inline from the function prototype and not have it at all.

So I consider my proposal completely invalid, please do not consider it.

[Martin_fr]

Just as a note, maybe it could be useful to extend -Se

Currently we have -Sew  -Sen -Seh  to error-out on warning, or notes.

Maybe -Seh123,199  could be accepted to only halt on notes 123 and 199? (not sure if numbers are unique across hint/note/warning - maybe -Se=123,199  to distinguish from giving the amount of errors to report? )

That way anyone can test if there code throws particular hints/notes/warnings.

[MarkMLl]

Would certainly be progress.

MarkMLl