[Q] "//go:fix inline" and how to deal with imports in writing custom analyzers?

[TheDiveO]

After some refactoring which resulted in packages (P, Q, ...) moving out of one of my modules ("M1") into a new module ("M2") I'm hitting a current limitation of "//go:fix inline" and that is in my case related to the fact that my P, Q, are unit test helpers; in particular, they're helpers to be used with Gomega and Ginkgo.

Now, M1.P.Foo looks like this:

//go:fix inline

func Foo() {

    ginkgo.GinkgoHelper()

    M2P.Foo()

}

Here, ginkgo.GinkgoHelper() marks this function (when seen on the call stack) as a helper that should not be reported, but instead its caller. When inlining, this call must not be inlined. Looking around, I don't see this more special case of go:fix inline to be supported.

Thus, I'm next looking into writing an golang.org/x/tools/go/analysis.Analyzer. The thing I'm currently struggling with is how to get the modifications of imports correct, because that involves finding the default local name for the import path, handling collisions (which in my case are normal), and then editing. Even getting the default local name looks tricky considering cases like "example.com/foo/go-bar" where the usual basename(dirname(path)) method will surely fail.

Looking around I notice several packages dealing with refacting imports, but these are all internal. From the perspective of writing custom analyzers:

1. does the Go project plan to make (after some cleanup I would suspect) such common refactoring/fixing helpers public?
2. for the time being, which internal code might be worth "hoisting" from its internal path into my analyzer support package(s)?

For those interested in the affected modules:

• github.com/thediveo/notwork -- esp. netns and mntns packages
• github.com/thediveo/spacetest

[Alan Donovan]

On Thursday, 2 April 2026 at 04:24:06 UTC-4 TheDiveO wrote:

After some refactoring which resulted in packages (P, Q, ...) moving out of one of my modules ("M1") into a new module ("M2") I'm hitting a current limitation of "//go:fix inline" and that is in my case related to the fact that my P, Q, are unit test helpers; in particular, they're helpers to be used with Gomega and Ginkgo.

Now, M1.P.Foo looks like this:

//go:fix inline

func Foo() {

    ginkgo.GinkgoHelper()

    M2P.Foo()

}

Here, ginkgo.GinkgoHelper() marks this function (when seen on the call stack) as a helper that should not be reported, but instead its caller. When inlining, this call must not be inlined. Looking around, I don't see this more special case of go:fix inline to be supported.

Correct. The inliner promises to be semantics preserving in general, but of course this is impossible if the callee uses reflection over the call stack, since inlining by definition changes the call stack, and human review is necessary to consider the implications of inlining on the call stack.

 

The thing I'm currently struggling with is how to get the modifications of imports correct, because that involves finding the default local name for the import path, handling collisions (which in my case are normal), and then editing. Even getting the default local name looks tricky considering cases like "example.com/foo/go-bar" where the usual basename(dirname(path)) method will surely fail.

Looking around I notice several packages dealing with refacting imports, but these are all internal. From the perspective of writing custom analyzers:

1. does the Go project plan to make (after some cleanup I would suspect) such common refactoring/fixing helpers public?
2. for the time being, which internal code might be worth "hoisting" from its internal path into my analyzer support package(s)?

There are indeed a lot of useful primitives in x/tools/internal, many of which have proven themselves stable and reliable; in due course we may publish them, especially as we start thinking about how to support dynamic execution of analyzers from the modules themselves. There are also a number of other functions that are more problematic or are still on probation, and need more thought. In the meantime, feel free to copy whatever functions you need.