//go:fix inline and the source-level inliner
1–10 of 81 posts
Re: //go:fix inline and the source-level inliner
#2Re: //go:fix inline and the source-level inliner
#3It 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")
}Re: //go:fix inline and the source-level inliner
#4If I follow, this isn't a compile time inline directive, it's a `go fix` time source transformation of client code calling the annotated function.
Per the post, it sounds like this is most effective in closed-ecosystem internal monorepo-like contexts where an organisation has control over every instance of client code & can `go fix` all of the call sites to completely eradicate all usage of a deprecated APIs:
> For many years now, our Google colleagues on the teams supporting Java, Kotlin, and C++ have been using source-level inliner tools like this. To date, these tools have eliminated millions of calls to deprecated functions in Google’s code base. Users simply add the directives, and wait. During the night, robots quietly prepare, test, and submit batches of code changes across a monorepo of billions of lines of code. If all goes well, by the morning the old code is no longer in use and can be safely deleted. Go’s inliner is a relative newcomer, but it has already been used to prepare more than 18,000 changelists to Google’s monorepo.
It could still have some incremental benefit for public APIs where client code is not under centralised control, but would not allow deprecated APIs to be removed without breakage.
Re: //go:fix inline and the source-level inliner
#5It 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") }
Or: your buggy code is no longer buggy.
Re: //go:fix inline and the source-level inliner
#6It 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") }
Great example, illustrating go1.26.1 go fix source inline transformation breaking program semantics. Raise it as a bug against go fix?
Re: //go:fix inline and the source-level inliner
#7I wonder why they chose to add these directives as comments as opposed to adding new syntax for them. It feels like a kludge.
Re: //go:fix inline and the source-level inliner
#8I wonder why they chose to add these directives as comments as opposed to adding new syntax for them. It feels like a kludge. https://wiki.c2.com/?HotComments
The //go:xyz comments are an established pattern in the Go tooling.
Re: //go:fix inline and the source-level inliner
#9It 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") }
Great example, illustrating go1.26.1 go fix source inline transformation breaking program semantics. Raise it as a bug against go fix?
As 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.
Re: //go:fix inline and the source-level inliner
#10It 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") }
Or: your buggy code is no longer buggy.
You claim listens right for this specified example. :D
It is just a demo.