I've found that any INLINE subroutine isn't inlined anymore, no matter if I use the -Si option or not.
This seems to be a bug, actually I've found bug 37241 (https://bugs.freepascal.org/view.php?id=37241) that seems similar but it says that it raises an internal error and that it is fixed in 3.2.0 but that's the compiler I'm using and it is not fixed (by the way I found Bug Tracker quite confusing).
Not sure what to do: Is it a feature or a bug? Is it fixed? Is it a new one?
About the bug tracker:
"Product version" is the version in which the reporter found the bug. Or in which it the developper confirmed it. In short: the version with the bug.
There should be a field "Fixed in Version", but mantis has its own issues and it is not visible.
If it was set, it can be seen in the "issue history" at the bottom. Also, if it is set, its usually set to trunk (e.g. here fpc 3.3.1) or indicate the hope of the developer to get the fix copied to an earlier release.
In this issue it is not set.
The same for FpcTarget or LazTarget fields.
...Thanks for the explanation. I still find it confusing but I have a better view about what happens.
It is quite easy to turn them off, e.g:It is not worksing:I explained that in the wiki a few years ago.
See https://wiki.freepascal.org/Turn_warnings_and_hints_on_or_off as I wrote. It DOES work with notes too... If it doesn't file a bug report about the noteIt works only via porject properties form interface (check off the options)
See my last remark: the wiki was cpmplete and correct but is vandalized by nitwits. ( Huntingkashket contribs will be reversed by me )Ok. Thanks
But anyway compiler should tell why it didn't inline inlined subroutines so they may be fixed or if it isn't possible to remove the INLINE keyword, shouldn't it?
Anyway I've revised all my INLINE subroutines and I can't see why they cannot be inlined. For example, why next code can't be inlined? I don't think it is just because it isn't parsed yet because it is used by several units, and units are parsed before they're used, aren't they?
Is the hint triggered when called in a different unit or the same unit? If the same unit, then see my example: if you want FindState to be inlined then any callsite inside the same unit needs to be after FindState.
Other possibility: is STATE_NOT_FOUND global or local to the unit?
I understand why the compiler isn't able in some cases, but anyway there should be a way to fix it; maybe 2 pass compilation although I understand it isn't feasible without rewriting most of the compiler (IIRC current compilation is done in a single pass). Anyway it is quite annoying.
Is the hint triggered when called in a different unit or the same unit? If the same unit, then see my example: if you want FindState to be inlined then any callsite inside the same unit needs to be after FindState.
Other possibility: is STATE_NOT_FOUND global or local to the unit?
Sometimes in the same unit, some times in other units.
Fixing the "same unit" the way you said is a mess, as I have the implementation in same order than the interface declarations, wich is helpful for maintenance. So changing that... Not sure but I think I have hundred methods in the engine and several docens in Allegro.pas. :(
What about the other units?
As said above if it's about cross-unit inline then the order is not important, but other things might be. Thus I ask again: is STATE_NOT_FOUND declared globally or locally? And is it used in a function that is declared as inline and is available from the interface section of the unit?STATE_NOT_FOUND is a RESOURCESTRING declared in the IMPLEMENTATION section. It is used by two methods, one declared as INLINE, the other isn't. The INLINE method is used by other units only (and never inlined).
Ok, this is nuts. It says it can't inline this: