If 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.
Can't golang devs prioritize something like annotations or other attribute/metadata system instead of writing these in comments? I'm pretty sure this must have been raised a lot of times before, so just wanted to ask if there is/are any specific reason(s)?
I know this is off-topic, and likely to get me down-voted, but hey! I'll live dangerously for the sake of repeating a hilarious (to me) .sig in a now ancient Usenet post.
These //go.* commands always remind me of this:
"""
//GO.SYSIN DD *
DOO DAH
DOO DAH
"""
(Why yes, that is IBM System 360 JCL from circa 1975. Why do you ask?)
As usual, great writeup and problem solving from Go team. One nitpick: wording "call to oldmath.Sub should be inlined" might be a bit confusing due to existing meaning of word "inlining" for functions (i.e. compiler inlining optimization). Without this article I would not be able to guess that this diagnostic message refer to something else.
12 comments
[ 3.1 ms ] story [ 27.5 ms ] threadPer 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.
https://wiki.c2.com/?HotComments
These //go.* commands always remind me of this:
"""
//GO.SYSIN DD *
DOO DAH
DOO DAH
"""
(Why yes, that is IBM System 360 JCL from circa 1975. Why do you ask?)