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.
--
βþ
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
