Archive · Week 11 · Mar 9 – 15, 2026from 2 items
This week the Go team focused on improving tooling and runtime ergonomics. Two notable items were released: a blog post explaining the new source‑level inliner in Go 1.26, and an accepted proposal that adds an “Error” flag to the JSON output of `go test`. Both changes aim to make Go code easier to maintain and to provide clearer signals to continuous‑integration systems.
Worth knowingruntime
Source‑level inliner in Go 1.26
- What changed
- The blog explains how Go 1.26’s source‑level inliner works and how it can help with self‑service API migrations.
- Production impact
- The source does not say.
- Try it
- Read the blog and experiment with the
//go:fixdirective on a small function to see the inlined code. - Source
- go.dev/blog/inliner
Explain it and run it
Understand it, then run it
Go 1.26 introduces a new feature called the source‑level inliner. It lets a package author add a comment //go:fix inline to a function, type, or constant. When the go fix command is run, any call to that function is automatically replaced in the source code with the body of the function, or with a call to another function if the body simply forwards to it. This means that if a library deprecates a function and wants callers to switch to a new one, the library can add the comment and the migration happens automatically for anyone who runs go fix. The change does not alter the language syntax or runtime; it is a tooling improvement that makes refactoring safer and easier. You can try it by adding the comment to a function and then running go fix on a file that calls it.
Run it now
// This program demonstrates the source‑level inliner introduced in Go 1.26.
// It uses a deprecated function that forwards to a new implementation.
// Running `go fix` on this file will replace calls to OldReadFile with os.ReadFile.
package main
import (
"fmt"
"os"
)
// OldReadFile is a deprecated wrapper around os.ReadFile.
//go:fix inline
func OldReadFile(name string) ([]byte, error) {
return os.ReadFile(name)
}
func main() {
// The following call will be inlined by go fix.
data, err := OldReadFile("example.txt")
if err != nil {
fmt.Println("error:", err)
return
}
fmt.Println("content:", string(data))
}
What it printed when we ran it on Go 1.27.1
error: open example.txt: no such file or directory
Run sends this program (for Solidity, the contract and its tests) to our own sandbox, where it is compiled and run once, with no network, and what it printed or the test report comes back here. Nothing is kept. Runs are counted per visitor for the day so everyone gets a turn; the details are on the legal page.
Worth knowingtooling
Annotate test output JSON with an “Error” flag
- What changed
- The proposal adds a boolean field “Error” to “output” actions in the JSON produced by
cmd/test2json. This field is true for output produced via(*testing.T).Error{,f}and(*testing.T).Fatal{,f}, and for the first few lines of a crash (but not the stack trace). - Production impact
- The source does not say.
- Try it
- Run
go test -jsonon a package that usest.Errorand inspect the resulting JSON for the new “Error” field. - Source
- github.com/golang/go/issues/62728
Explain it
Understand it, then run it
The go test -json command turns test output into a stream of JSON objects. Until now, every line of output—whether it came from t.Log, t.Error, or a panic—looked the same. The change adds a new boolean field called Error to each JSON object that represents a line of output. If the line was produced by t.Error, t.Fatal, or the first few lines of a crash, Error is true; otherwise it is false. This lets tools know which lines are part of a test failure rather than just noise.
Exercise
Exercise – Using the source‑level inliner to migrate a deprecated API
Write a small program that uses the deprecated ioutil.ReadFile function. Add the //go:fix inline directive to the ioutil.ReadFile implementation so that, when you run go fix, the call is automatically replaced with a call to os.ReadFile. After running go fix, the program should compile and run without importing the ioutil package.
> Goal – Show that the inliner can replace a call to a deprecated function with its new implementation by simply adding a comment.
// main.go
package main
import (
"fmt"
"io/ioutil"
)
func main() {
data, err := ioutil.ReadFile("hello.txt")
if err != nil {
fmt.Println("error:", err)
return
}
fmt.Println(string(data))
}
Show a solution
// main.go
package main
import (
"fmt"
"os"
)
func main() {
data, err := os.ReadFile("hello.txt")
if err != nil {
fmt.Println("error:", err)
return
}
fmt.Println(string(data))
}
What it printed when we ran it on Go 1.27.1
error: open hello.txt: no such file or directory
Run sends this program (for Solidity, the contract and its tests) to our own sandbox, where it is compiled and run once, with no network, and what it printed or the test report comes back here. Nothing is kept. Runs are counted per visitor for the day so everyone gets a turn; the details are on the legal page.
The 60-second version
Good morning. This week the Go team added a new source‑level inliner in Go 1.26, explained in a blog post. It lets you write `//go:fix` directives to hint the compiler to inline functions at the source level, which can help with self‑service API migrations. In the tooling space, an accepted proposal now adds an “Error” flag to the JSON output of `go test`. This flag marks output that comes from `t.Error` or `t.Fatal`, and the first few lines of a crash, making it easier for CI systems to pick out the most relevant test failures. Those are the highlights for this week.
Written by gpt-oss-20b · claims checked against the sources · archive, not individually reviewed