On 24 jan 2007, at 13:01, Пётр Косаревский wrote:
Implementing it for all cases is non-trivial and has low priority.
Actually, implementing the warning is easy, but always adding the
reason why it isn't inlined is more difficult.
I think, that there are many reasons, which will not help me a
single bit.
Reasons are e.g.
a) recursively calling an inlined procedure
b) a procedure containing an assembler block
c) calling an procedure which is declared inline before its
implementation has been parsed (can be both because it's in another
unit of which only the interface has been parsed, or in the current
unit but the implementation has been parsed yet)
In the future, other less straightforward rules may be added as well
(like "the compiler thinks the code would probably get slower rather
than faster if this function is inlined").
However, reliable warning without explanations seems to be a good
thing.
How? I think it's completely useless if you have no idea what it's
caused by and what to do about it.
Jonas_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
