Leveraging Source-Level Inlining for Go Code Modernization

Introduction

Go 1.26 ships a completely reengineered go fix subcommand, designed to help developers keep their codebases current with modern language and library practices. Among its capabilities is a powerful source-level inliner that enables any package author to craft straightforward, safe API migrations and upgrades. This article explores how the source-level inliner works, its integration with existing tools, and the opportunities it opens for self-service code modernization.

What is Source-Level Inlining?

Source-level inlining replaces a function call with a copy of the called function's body, substituting actual arguments for parameters. Unlike the inlining performed by a compiler on an internal intermediate representation, this transformation durably modifies the source code visible to developers and version control systems.

The Algorithm Behind It

First developed in 2023, the algorithm handles many subtle correctness issues that arise when moving code from a call site into the caller's context. It correctly renames variables to avoid shadowing, resolves import paths, and preserves the semantic meaning of expressions. This makes it a reliable foundation for refactoring tools.

Comparison with Compiler Inlining

While compiler inlining aims to improve runtime performance by eliminating call overhead, source-level inlining focuses on code clarity and maintainability. The compiler's transformation is ephemeral—it affects only the generated machine code—whereas source-level inlining produces permanent changes to the Go source files. This distinction is crucial for understanding where each technique is best applied.

How It Works in Practice

Using with gopls

If you've used the Inline call interactive refactoring in gopls (accessible via the Source Action menu in editors like VS Code), you've already benefited from the source-level inliner. When applied, a call such as sum(a, b, c) inside a function named six is replaced by the body of sum, with variables appropriately adapted. The result is often clearer and more concise code, especially when the inlined function is small and used only once.

The inliner also powers other gopls refactorings, such as Change signature and Remove unused parameter, because it safely rewrites all call sites to match the new function signature.

Integration with go fix

In Go 1.26, the same inliner is one of the analyzers within the new go fix command. This allows package authors to define self-service modernization rules that automatically update client code when an API changes. For example, a library maintainer can provide a fix that replaces deprecated function calls with their recommended replacements, using the inliner to safely expand and adjust invocations.

Benefits for Package Authors

Self-Service Modernizers

The source-level inliner is the first fruit of Go's effort to deliver self-service analyzers and modernizers. Previously, only the Go team could add bespoke fixes for specific language or library features. Now any package author can write a simple rule describing how to migrate from one API to another, and users of that package can apply it with a single go fix command.

Safe and Correct Transformations

Correctness is paramount. The inliner's algorithm has been rigorously tested to handle edge cases like:

• Variable capture and closure semantics
• Import path adjustments
• Handling of blank identifiers and dot imports
• Preserving order of evaluation for side effects

Because the transformation is performed at the source level, developers can immediately review the changes in a pull request, ensuring full visibility into the modernization process.

Looking Ahead

The source-level inliner is a foundational building block for future tooling. Beyond the current capabilities, it may enable even more sophisticated refactoring and analysis. For now, it lowers the barrier for package authors to provide upgrade paths and helps the entire Go ecosystem stay up-to-date with less manual effort.

To get started, ensure you're using Go 1.26, explore the go fix documentation, and consider how you can leverage this new power to smooth API migrations in your own projects.