logoalt Hacker News

tapirl • yesterday at 9:10 PM • 4 replies • view on HN

It looks the following code will be rewritten badly, but no ways to avoid it? If this is true, maybe the blog article should mention this.

    package main
    
    //go:fix inline
    func handle() {
        recover()
    }
    
    func foo() {
        handle()
    }
    
    func main() {
        defer foo()
        panic("bye")
    }

Replies

tapirl • yesterday at 10:06 PM

Another example (fixable):

    package main

    import "unsafe"

    //go:fix inline
    func foo[T any]() {
        var t T
        _ = 1 / unsafe.Sizeof(t)
    }

    func main() {
        foo[struct{}]()
    }
Go is a language full of details: https://go101.org/details-and-tips/101.html
➕ show 1 reply
arjvik • yesterday at 11:04 PM

recover()'s semantics make it so that "pointless" use like this can be inlined in a way that changes its semantics, but "correct" use remains unchanged.

Yes, maybe some code uses recover() to check if its being called as a panic handler, and perhaps `go fix` should add a check for this ("error: function to be inlined calls recover()"), but this isn't a particularly common footgun.

shoo • yesterday at 9:26 PM

Great example, illustrating go1.26.1 go fix source inline transformation breaking program semantics. Raise it as a bug against go fix?

➕ show 1 reply
arccy • yesterday at 9:20 PM

Or: your buggy code is no longer buggy.

➕ show 1 reply