13 ms·
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
by tapirl 6mo ago
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")
}
- arccy 6mo agoOr: your buggy code is no longer buggy.
- tapirl 6mo agoYou claim listens right for this specified example. :D It is just a demo.
- shoo 6mo agoGreat example, illustrating go1.26.1 go fix source inline transformation breaking program semantics. Raise it as a bug against go fix?
- tapirl 6mo agoAs I have mentioned, no ways to fix it. Because it is hard to know whether or not the handle function is called in a deferred call.
- tapirl 6mo agoAnother 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 https://go101.org/details-and-tips/101.html
- tapirl 6mo agosimilar: package main //go:fix inline func foo[T [8]byte | [4]uint16]() { var v T var n byte = 1 << len(v) >> len(v) if n == 0 { println("T is [8]byte") } else { println("T is [4]uint16]") } } func main() { foo[[8]byte]() }
- tapirl 6mo agoanother: package main type T = [8]byte var a T //go:fix inline func foo() T { return T{} } func main() { if foo() == a { } } filed: https://github.com/golang/go/issues/78170 https://github.com/golang/go/issues/78170 and https://github.com/golang/go/issues/78169 https://github.com/golang/go/issues/78169
- arjvik 6mo agorecover()'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.
- tapirl 6mo ago> ... and perhaps `go fix` should add a check for this ( This is an impossible task. For a library function, you can't know whether or not the function is defer called. Maybe this is not an important problem. But it would be better if the blog article mentions this.
- hrmtst93837 6mo ago[flagged]
- adonovan 6mo agoThanks, that's a bug. We should never inline a function that directly calls recover. I've filed https://go.dev/issue/78193 https://go.dev/issue/78193.