The inliner uses the go/ast formatter, which automatically inserts parens only when they are required by precedence. However, there are two situations in which the inliner currently inserts brackets unnecessarily.

The first situation is that, when inlining a call to {return expr}, the inliner may replace the CallExpr by (expr) with extra parens. The reason these parens are sometimes needed is that the formatter can only apply its precedence algorithm when it sees the parent node of the new tree. However, the inliner currently works by formatting the "new" tree in isolation, then textually splicing it into the original file in place of the CallExpr, so the formatter does not get to see the context. The inliner will need to reproduce the computation as to whether these parens are required in the caller context.

The reason the inliner uses textual splicing is so that it does not reformat any more of the caller syntax than necessary, and the reason for that is that when formatting a tree that contains nodes from two files, at most one of them can have its comments correctly handled by the formatter because comments are not stored in the tree but in a position-keyed side table. The inliner chooses to preserve comments in the callee when formatting, since the callee's function body often contains comments, whereas the caller syntax (argument expressions) rarely does. However, when future strategies used by the inliner expand the scope of the refactoring (e.g. by replacing not just the CallExpr or its coextensive ExprStmt, but the enclosing BlockStmt), then this will become a bigger problem.

The second situation in which inlining inserts extra brackets is when replacing a call func(params){block}(args) by a block { var (params = args); body }. In this case the extra block may be necessary in general to avoid conflicts between names in the caller and callee blocks, but it should be easy to detect when these sets are disjoint and omit the brackets. The challenge is that omitting the brackets means replacing a single statement (e.g. ExprSmt) by not one statement (BlockStmt) but two or more (the parameter binding decl and then then rest of the body). So, we can't simply replace one tree with another but will need to replace some sequence of statements in a list with some other sequence of statements (e.g. in its parent BlockStmt). The tricky part is that this requires that we expand the scope of the "old" tree to an enclosing block (as ominously mentioned earlier), which has serious consequences for the fidelity of caller comment handling. I suspect it might be simplest to again use textual (not tree-based) processing: insert the BlockStmt, remember where its braces are, format the file, replace the braces with spaces, then format the file again.

So we see that fundamentally both of these problems are yet more consequence of #20744, which I think it is really time for us to fix.

@findleyr @timothy-king