| ▲ | tapirl 11 hours 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. | ||||||||||||||
| ▲ | arjvik 10 hours ago | parent | next [-] | |||||||||||||
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 11 hours ago | parent | prev | next [-] | |||||||||||||
Great example, illustrating go1.26.1 go fix source inline transformation breaking program semantics. Raise it as a bug against go fix? | ||||||||||||||
| ||||||||||||||
| ▲ | arccy 11 hours ago | parent | prev | next [-] | |||||||||||||
Or: your buggy code is no longer buggy. | ||||||||||||||
| ||||||||||||||
| ▲ | tapirl 10 hours ago | parent | prev [-] | |||||||||||||
Another example (fixable):
Go is a language full of details: https://go101.org/details-and-tips/101.html | ||||||||||||||
| ||||||||||||||