x/tools/internal/refactor/inline: good starter projects

[adonovan]

Below is a list of starter projects for anyone who wants to get their hands dirty in the inliner logic. Before starting work on any item, please fork it off into a separate issue, briefly stating the approach you plan to take.

• allow conversions (other than []byte(string), which observably allocates) to be considered duplicable (x/tools/internal/refactor/inline: allow conversions to be considered duplicable #67589).
• omit unnecessary interface conversions in argument passing (x/tools/internal/refactor/inline: avoid unnecessary interface conversions #68554).
• simplify "binding decl" to use param := arg when it's not necessary to state the type.
• improve precision of check of whether arg elimination removes last ref to a caller var...
  ...and instead of preventing elimination, blank out the var decl.
• avoid imports.Process by reimplementing just the algorithm we need.
• choose better local names for renaming imports
• avoid unnecessarily renaming imports (may need additional inputs?) (x/tools/internal/refactor/inline: analyzer generates unnecessary import renames #67281)
• implement "void tail call" strategy (i.e. f() statement before return stmt). If the return stmt is pure, this is sound even if the callee uses defer.
• implement parameterless call to { stmt; return expr } from one of these contexts:

        //    x, y     = f()
        //    x, y    := f()
        //    var x, y = f()

• use binding decls even with the literalization strategy: it's easier and more natural to read func() { var param=arg; ... } () than func(param) { ... } (arg). (Beware: binding decls cover params and named result vars; they may need to be teased apart.)
• clean-up (?): unify pure, duplicable, and effects into a single pass.
• use callee's FileSet (calleeFset) to format the new node (res.new), as it is mostly callee code. This should reduce comment loss. (Beware: it seems to introduce spurious newlines. Why?)

See also:

• x/tools/internal/refactor/inline: support inlining functions with type parameters #68236
• x/tools/internal/refactor/inline,x/tools/gopls: undo variadic elimination when it is safe to do so #63717
• x/tools/internal/refactor/inline: reduce call if neither binding decl nor callee body would create name conflicts #70759

More challenging projects:

• Translate if f(); cond { ... } to { fbody; if cond { ... } } when the inlining of f() is not a simple expression.- [ ] Add a control flow analysis that is more precise than the current "single assignment" predicate. Currently, a binding declaration is required if an argument is a variable that is not "single assignment". But if all the assignments can be proved to occur before or after the call (but not during it using lambdas) then a binding declaration may not be needed.
• Add an alias analysis so that effects on memory by the callee can be localized to particular variables, allowing writes to commute with reads if they cannot alias.
• Better handling of spread calls (f(g()) where g returns >1 result).

[aimuz]

Hello, what do I need to start with

[adonovan]

Hello, what do I need to start with

Hi @aimuz, thanks for your interest! The task requires at least a little familiarity with the basic concepts of compilers, and with the APIs of Go's go/ast and go/types packages. Otherwise the learning curve will be steeper; you may find https://golang.org/s/types-tutorial helpful.

Does any of the items listed above seem appealing? If there's one in particular that you want to start with, I suggest you create a separate issue for it, claim it for yourself, state briefly (a sentence or two is fine) what approach you plan to take, and ask any question you have about the approach. We can comment on the separate issue without confusing this one.

[aimuz]

Thanks for the guide, have a nice day!

[vladvalkov]

Hi @adonovan! Are these still relevant?
Should the claimed issue follow any existing template? (or can it be just a blank issue referencing this one?)

[adonovan]

Hi @vladvalkov, yes they are still relevant. No particular template, just include the relevant information and link from here to the new issue.

IMHO the best starter tasks are:

• allow conversions (other than []byte(string), which observably allocates) to be considered duplicable.
• improve precision of check of whether arg elimination removes last ref to a caller var...
• choose better local names for renaming imports