[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