[SOLVED] Hint: "inherited" not yet supported inside inline procedure/function lazarus / 12-Debugger ---------------------------------------------------------------------- Eugene Loza · 2017-08-03 12:59 I've seen an "Hint: "inherited" not yet supported inside inline procedure/function" which is a very good one... but there's a problem, it doesn't point to any line of code or even to a corresponding unit. Is there any way to find the source line? Because the code is huge (over 20k lines) and I have an extensive use of inline/inherited logic... ---------------------------------------------------------------------- Thaddy · 2017-08-03 16:09 Compile with lineinfo. Anyway: it is a hint. The logic of combining inline with inherited will not work. The compiler will NOT inline the code. At the moment it is useless but it may work in a future version. Note that the code will work, just not inlined... ---------------------------------------------------------------------- Eugene Loza · 2017-08-03 16:16 QuoteNote that the code will work, just not inlined...Yes, that's the problem. I inline only time-critical code. If it won't work inlined I'd better copy the whole "inherited" part than experience a FramesPerSecond drop. Well... on the other hand it doesn't look very important (and the speed drop won't be critical anyway), so I'll find them eventually. Just with a point to specific lines of code it'd be faster and easier ---------------------------------------------------------------------- Eugene Loza · 2017-08-05 10:55 I've scanned all my code and... didn't found a single issue where inline is mixed with inherited (or virtual mehtods)... What could that mean? What did I do wrong? Maybe I've forgotten to specify inline twice? Where should it be specified for methods - both in class declaration in interface and in implementation, right? Couldn't reproduce it on a "Clean" case - with any combination of "inline" statements / inheritance. ---------------------------------------------------------------------- Thaddy · 2017-08-05 12:14 rtl-generics is a package that anticipates it and generates the hints... Not the only one in a trunk compile, btw... You do not use it on a single line. It manifests itself when an inlined overridden method calls inherited in the body. E.g: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i    procedure TSomeClass.SomeMethod(const something:integer);inline;override;   begin      inherited SomeMethod(something);      DoSomethingExtra;  end;Even if inherited and current SomeMethod are  very simple, the compiler can not resolve this yet and inline the whole of it. Hence (yet) in the hint. But the code works. ---------------------------------------------------------------------- Eugene Loza · 2017-08-05 12:25 Quote from: Thaddy on August 05, 2017, 02:14:13 pmprocedure TSomeClass.SomeMethod(const something:integer);inline;override;I'll double check that again, but I'm 100% sure there are no such occasions in the code... ---------------------------------------------------------------------- Thaddy · 2017-08-05 12:26 Then you are wrong.... Maybe YOUR code, but not a full FPC built... ---------------------------------------------------------------------- Eugene Loza · 2017-08-05 12:29 Quote from: Thaddy on August 05, 2017, 02:26:58 pmMaybe YOUR code, but not a full FPC built...Or CastleGameEngine I extensively use... But for that reason it'd be very nice to know the lines where the hint is issued I'll try to figure it out... or give up until some future... ---------------------------------------------------------------------- Thaddy · 2017-08-05 12:31 You will get the lines if you use lineinfo... You should know that. -glh ---------------------------------------------------------------------- Eugene Loza · 2017-08-05 20:09 Emmm... I'm using -gl, I can't find -glh in documentation / project options... did you mean -gl and -gh together? They're both on and display line numbers for other errors/hints/warnings and heap trace with line numbers perfectly. ---------------------------------------------------------------------- Eugene Loza · 2017-08-05 20:19 Maybe, something wrong with my Lazarus installation? It stopped showing ALL hints and warnings (even user-defined) at all after I've manually added -glh option to compiler (even after I removed it)... Even if I "build clean"... ---------------------------------------------------------------------- Eugene Loza · 2017-08-07 12:21 Found the source of disappeared hints/warnings. For some reason they load only after I start editing the project (when the first delay before the suggestion passes), i.e. some part of IDE is not initialized at start-up (bug?). ---------------------------------------------------------------------- Thaddy · 2017-08-07 13:26 Quote from: Eugene Loza on August 05, 2017, 10:09:51 pmEmmm... I'm using -gl, I can't find -glh in documentation / project options... did you mean -gl and -gh together? They're both on and display line numbers for other errors/hints/warnings and heap trace with line numbers perfectly. -glh is allowed: the -g option allows to specify its options in one go. -gl -gh means the same as -glh. There are many more compiler options that can  use this short notation, like -vwhiq or -XXc This is also documented. ---------------------------------------------------------------------- Thaddy · 2017-08-07 13:28 Quote from: Eugene Loza on August 07, 2017, 02:21:04 pmFound the source of disappeared hints/warnings. For some reason they load only after I start editing the project (when the first delay before the suggestion passes), i.e. some part of IDE is not initialized at start- up (bug?). No it is not a bug: only when you really edit, the sourcecode gets parsed for validity. Note you can get rid of the buggers by adding {$WARN 3123 OFF}{$WARN 3124 OFF} at the top of your *.lpr file (or main program.pas) ---------------------------------------------------------------------- michalis · 2017-08-21 14:44 Three random remarks: 1. Note that the new CastleVectors API from Castle Game Engine uses "inline" for many methods. Are you sure that it's not the fault of my CastleVectors? 2. As Thaddy writes, inlining virtual methods doesn't work. Virtual methods are called through a pointer, the idea is that the compiler doesn't know (at compilation time) what is the actual code being executed. So, it also cannot inline the method.   Note that the "Whole Program Optimization" can analyze the code and perform "devirtualisation", when possible. See the documentation on http://wiki.freepascal.org/Whole_Program_Optimization . Although I never tested it, and I have no idea whether the "devirtualization" is done early enough to allow inlining to work. But, *in theory*, it could enable inlining of (some) of the cases when you use virtual methods.   (But it will only affect the cases when the analysis can prove that your virtual method call is actually always calling only the one possible method implementation. Which may not be helpful at all in your case.) 3. I don't think that "-gl" has any effect on the hints you see *when compiling*. At least it's not documented like that (documentation says "-gl" does "Use line info unit (show more info with backtraces)"). And I never observed it.   The -gl does the same thing as adding the LineInfo unit at the beginning of the uses clause of your program. So it allows you to see the line information (e.g. in backtraces) at runtime, but I *think* it has no effect on the information you see at compile time. If you can show me an example when the "-gl" changes what you see at compile- time, I would happily be corrected ---------------------------------------------------------------------- Eugene Loza · 2017-10-28 05:22 Just in case anybody is interested. FPC 3.1.1 shows the origin of the hint/error. It's a FGL unit, which indeed has strong use of inline within inherited.