x/tools/internal/refactor/inline: readiness checklist

[adonovan]

This issue records the list of outstanding items before we call the inliner ready to announce in gopls:

• Finish the "everything" test (https://go.dev/cl/528495) and fix all the bugs that it unearths.
• Opt: relax our strict stance on implicit conversions as a reason not to perform parameter substitution. (Implicit conversions such as int -> any do have a non-zero dynamic cost that inlining may multiply, but we've decided that's ok.) (https://go.dev/cl/530975)
• Opt: compute when parens and braces are unnecessarily inserted and don't do that. (x/tools/internal/refactor/inline: don't insert parens/braces unnecessarily #63259)
• Opt: analyze the order of effects in the callee to allow more parameter substitutions (https://go.dev/cl/526420).
• Bug: type errors resulting from var -> const substitution (x/tools/internal/refactor/inline: replacing a variable by a constant may cause type error #62664)
• Bug: shadowing errors resulting from introduced package names (x/tools/internal/refactor/inline: missing shadowing check when forming qualified identifiers #62667)
• Bug: make sure cgo inputs don't cause a crash (https://go.dev/cl/529877)
• Bug: x/tools/internal/refactor/inline: PkgName conflict #63298
• Polish the documentation for the release notes. (https://go.dev/cl/532276)

@findleyr

[adonovan]

Status update: I ran the inliner on every function call in the x/tools repo. The only remaining known bugs are #62664 and #62667.

[adonovan]

Here's a list of starter projects for anyone who wants to get their hands dirty in the inliner logic:

• paren elimination x/tools/internal/refactor/inline: don't insert parens/braces unnecessarily #63259
• support inlining of generic functions or methods
• 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?)
• implement "void tail call" strategy (i.e. f() statement before return stmt)
• implement parameterless call to { stmt; return expr } from one of these contexts:

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

[adonovan]

All done! Let's not forget the handy to-do list above though. Moved to #63352