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 22 · May 26 – Jun 1, 2025from 5 items

The Go team accepted several proposals that refine tooling, standard library documentation, and security helpers. The changes focus on making migrations easier, clarifying slice behavior, adding CSRF protection helpers, and deprecating legacy AST utilities.

Breakingstdlib

go/ast: deprecate MergePackageFiles (it's not used, and buggy)

What changed
go/ast.MergePackageFiles is now deprecated because it produces broken merges when parser.ParseComments is enabled.
Production impact
The source does not say.
Try it
Search your code for uses of MergePackageFiles and replace them with alternative parsing logic.
Source
github.com/golang/go/issues/7124

Breakingstdlib

go/ast: deprecate FilterPackage, PackageExports, MergePackageFiles

What changed
All functions that operate on the deprecated ast.Package type (FilterPackage, PackageExports, MergePackageFiles) and the related MergeMode type are now deprecated.
Production impact
The source does not say.
Try it
Refactor any AST‑processing code that relies on ast.Package to use the newer *ast.File‑based helpers instead.
Source
github.com/golang/go/issues/73088
Explain it

Understand it, then run it

The Go standard library has a package called go/ast that represents Go source code as a tree of nodes. In older versions of the library, a type named ast.Package was used to hold a whole Go package, and several helper functions – FilterPackage, PackageExports, and MergePackageFiles – operated on that type. Those functions are now marked as deprecated, meaning they are still available but are discouraged from use because the type they rely on, ast.Package, is itself deprecated. The change does not add new features; it simply signals that developers should use newer alternatives that work with individual ast.File objects instead.

Worth knowingtooling

cmd/fix: automate migrations for simple deprecations

What changed
The go fix subcommand can now automatically rewrite trivial API changes such as replacing a function call or constant with another.
Production impact
The source does not say.
Try it
Run go fix ./... on a module that contains a deprecated API to see if the tool updates the code.
Source
github.com/golang/go/issues/32816
Explain it and run it

Understand it, then run it

Run it now

Todaygo
// This program demonstrates the new go:fix directives.
// It will not compile until the change ships in a future Go release.
// The comments below describe how go:fix would rewrite the code.

package main

import "fmt"

// Deprecated: Use io.SeekStart instead.
//go:fix-to io.SeekStart
const SEEK_SET int = 0

func main() {
	// Before go:fix, this would use the old constant name.
	// After go:fix, the line below would be rewritten to use io.SeekStart.
	fmt.Println(SEEK_SET)
}

What it printed when we ran it on Go 1.27.1

0

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 knowingstdlib

slices: document behavior w.r.t. nil

What changed
The documentation of the slices package now explicitly states how each function handles nil arguments, including that slices.Clip and slices.Clone preserve nilness and that slices.Concat returns nil only when the result is empty.
Production impact
The source does not say.
Try it
Read the updated slices documentation and verify that slices.Clone(nil) returns nil.
Source
github.com/golang/go/issues/73604
Explain it and run it

Understand it, then run it

The slices package in Go has new documentation that explains how its functions behave when you pass a nil slice. A nil slice is a slice value that has no underlying array; it is different from an empty slice that has an array of length zero. Previously the docs did not say what would happen if you called functions like Clip, Clone, or Concat with a nil slice. Now the docs state that Clip and Clone keep the slice nil, and that Concat only returns nil when the combined result is empty.

Run it now

Todaygo
// This program demonstrates how Go handles nil slices with built‑in
// operations. It does not use the experimental slices package because
// that package is not part of the standard library and cannot be imported
// in a sandboxed Go 1.27.1 environment.
package main

import "fmt"

func main() {
	// A nil slice has no underlying array and its value is nil.
	var nilSlice []int
	fmt.Printf("nilSlice is nil: %v\n", nilSlice == nil)

	// Converting an empty composite literal to a slice yields a non‑nil slice.
	emptyLiteral := []int{}
	fmt.Printf("emptyLiteral is nil: %v\n", emptyLiteral == nil)

	// Slicing a nil slice preserves nilness.
	var x []int
	y := x[:0]
	fmt.Printf("x[:0] preserves nilness: %v\n", y == nil)

	// Append to a nil slice returns a non‑nil slice unless the result is empty.
	// Here we append nothing, so the result remains nil.
	z := append(x, []int{}...)
	fmt.Printf("append(nil, []int{}...) is nil: %v\n", z == nil)

	// Appending an element to a nil slice creates a non‑nil slice.
	w := append(x, 42)
	fmt.Printf("append(nil, 42) is nil: %v\n", w == nil)
}

What it printed when we ran it on Go 1.27.1

nilSlice is nil: true
emptyLiteral is nil: false
x[:0] preserves nilness: true
append(nil, []int{}...) is nil: true
append(nil, 42) is nil: false

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 knowingstdlib

net/http: add CrossOriginForgeryHandler

What changed
The net/http package now includes CrossOriginProtection, a helper that rejects non‑safe browser requests from a different origin based on the Sec-Fetch-Site or Origin headers.
Production impact
The source does not say.
Try it
Create a CrossOriginProtection instance and wrap an existing handler to see how it blocks unsafe cross‑origin requests.
Source
github.com/golang/go/issues/73626
Explain it

Understand it, then run it

The net/http package now has a helper called CrossOriginProtection. It is meant to stop a browser from sending a request that changes state (like a POST) when that request comes from a different website. The helper looks at two HTTP headers that browsers add: Sec-Fetch-Site and Origin. If the request is not a safe method (GET, HEAD, or OPTIONS) and the headers say the request came from another origin, the helper will reject it. If the headers are missing, the request is allowed – the helper assumes it is either a same‑origin request or not coming from a browser.

Exercise

Pick a small Go module that uses a deprecated go/ast function (e.g., MergePackageFiles). Run go vet or golangci-lint to see the deprecation warning, then refactor the code to use the recommended *ast.File helpers. Verify that the module still builds and that the linter no longer reports the deprecation.

The 60-second version

Today the Go team added a new helper to the standard library that makes it easier to keep your web services safe from cross‑origin request forgery. The `net/http` package now ships with a `CrossOriginProtection` type that you can drop into your handler chain. It automatically checks the `Sec‑Fetch‑Site` and `Origin` headers, allowing only safe methods from the same origin or from trusted origins you specify. If you’re running a Go web service that relies on the standard `http` server, you can add this protection with a single line of code and immediately tighten your CSRF defenses. In addition, the team refined the `go fix` tool so that simple API migrations can be applied automatically, making it easier to keep your code up to date with the latest library changes. Finally, the `slices` package documentation now spells out how nil slices are handled, and the AST package has deprecated several legacy helpers that operate on the old `ast.Package` type. These updates help you write clearer, safer, and more future‑proof Go code.

Written by gpt-oss-20b · claims checked against the sources · archive, not individually reviewed