This site is being rebuilt and some pages are out of date. For current details, write to [email protected]. This notice goes away when the rebuild is done.

No analytics unless you allow it, no tracking. This site keeps in your browser the language you pick, the theme, its colour, which site you chose, the currency on the pricing page and that you closed this notice; signing in adds session cookies. The legal page has the details.

Sign in

Quiet Pager · Radar

What changed in Go, Rust and Solidity this week.

What changed this week, from each project's own release notes, proposals and issues, with an exercise you can run for each change.

Written by a model · reviewed by a person · published Mondays · Atom feed

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:fix directive 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

Todaygo
// 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 -json on a package that uses t.Error and 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.

Startergo
// 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
Solutiongo
// 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