[fpc-devel] Streamlining TVMTBuilder.generate_vmt after r41716 & r41884

[Blaise at blaise.ru]

On 03.08.2019 15:01, Sven Barth via fpc-devel wrote:
> In principle one could do that, though more often than not inside the compiler maintainability beats performance. I'd prefer an opinion of Florian and/or Jonas on this though...

Leaving the issue of current_filepos for a moment, the change would be this:
-------8<-------
                  { VMT entry }
                  if is_new_vmt_entry(tprocdef(def),overridesclasshelper) then
                    add_new_vmt_entry(tprocdef(def),overridesclasshelper);
+                { hidden params }
+                handle_calling_convention(tprocdef(def),[hcc_insert_hidden_paras]);
                end;
            end;
-        insert_struct_hidden_paras(_class);
          build_interface_mappings;
-------8<-------
I would say, this is quite maintainable: replacing one call for another.
After r41884, the insertion of hidden parameters is already tightly coupled with VMT generation. In fact, it is no longer VMTBuilder, it is now ObjectDefPostprocessor :)

> What difference would it make for closures? In the end you'd still need to ensure that handle_calling_convention isn't called twice.

1) I would rather ensure it on a per-method basis;
2) I would rather add a check inside the combined loop above, instead of modifying insert_struct_hidden_paras and needlessly affecting RECORDs.

-- 
βþ