dynamically add trivial inline for cross-module exports

[jeparlefrancais]

In GitLab by @matthargett on Oct 3, 2021, 13:04

per #46 , discover when a wrapper function for things that are const-return in code or via those rules.

let's say that we have:
SchedulerFeatureFlags.new.lua:

local exports = {
  debug = false
}
exports.taskAPI = false
exports.retryCount = 0
exports.warningPrefix = ""
return exports

and in Scheduler.lua we have:

local flags = require(script.Parent["SchedulerFeatureFlags.new"])
local exports = {}
exports.markTask = function(...)
    if not flags.taskAPI then
      debug.profilebegin("label")      
    end
  end

exports.runTask = function(fn)
  local ok, _ = pcall(fn)
  if not ok then
    for i=1, flags.retryCount do
      pcall(fn)
    end
  end
end

main.lua:

local Scheduler = require(script.Parent.Parent.Scheduler)
Scheduler.markTask()
Scheduler.runTask(function() print("Zappanese") end)

if I set my configuration to const fold SchedulerFeatureFlags.new and Scheduler, main would end up as:
->

\n  --markTask is now a no-op flags:taskAPI = false -> Scheduler:markTask -> empty function -> remove no-op function calls
pcall(fn)\n --flags:retryCOunt = 0 -> runTask:for i=1, 0 -> runTask:loop removed -> runTask empty not ok branch removed -> local ok variable removed -> inline (now) trivial function export that is net netrual (or better) in terms of character count -> remove unused require

a couple salient details:

1. darklua might have to discover the leaf nodes of the module dependency graph and sort by those first so that everything "bubbles up" reasonably
2. if the same module name is discovered with different exports, darklua should blow up since it then may not be able to inline safely with this rule. I don't think this comes up in the above scenario in the target codebase, but something that'd be good to fortify against.
3. if inlining a trivial function exported from another module isn't net neutral in terms of character count for a specific call site, don't inline at that call site.
4. and function that uses file-local imports (that haven't been inlined/const-folded away) isn't trivial.
5. with this approach, running multiple iterations of the rule set per-file and across the entire module closure will be profitable. we may want to set a max ruleset iteration count for files and the whole program, and bail early if a given iteration of the ruleset didn't result in net new optimizations versus the previous iteration
   5a. we'll want to be really right about avoiding reversibility, where running an iteration on a file/whole program flips a given piece of code back and forth.