Duplicate imports with different names in multiple files cause error

[nkovacs]

Assuming you have these two files:

package foo

import (
    pkg1 "github.com/user/pkg"
)

type FooStruct{}

func (f *FooStruct) One(pkg1.Foo) {
}

package foo

import (
    pkg2 "github.com/user/pkg"
)

func (f *FooStruct) Two(pkg2.Foo) {
}

If you pass both files to ifacemaker, it will generate:

import (
    pkg1 "github.com/user/pkg"
    pkg2 "github.com/user/pkg"
)

type FooInterface {
    One(pkg1.Foo)
    Two(pkg2.Foo)
}

which is not valid because of the duplicate imports.

Similarly problematic are pkg1 "github.com/user/pkg" + "github.com/user/pkg" and even pkg "github.com/user/pkg" + "github.com/user/pkg".

I'm not sure if it's worth fixing this. The hardest part is probably finding an alias that doesn't conflict, after that, aliasing everything should be easier.

[vburenin]

This is definitely an interesting issue that can point to the naming inconsistency in the original code. I think it is worth fixing, but it would be good to print a warning that two different names are used.

[nkovacs]

I've implemented the warnings.

It's possible to fix this properly (i.e. automatically generate a non-conflicting alias), but it's quite complicated.

Since the package name doesn't have to be the same as the import path's last element, you have to find and parse imported packages to find out their actual package names, so that you can then find the SelectorExprs that need to be renamed. Actually I already did this in counterfeiter: maxbrunsfeld/counterfeiter#74, but counterfeiter already had code to find imported packages, because it already had to parse imports. It also already had code to rewrite the ast.
Functionality for rewriting the ast is missing from the standard library, so that also makes things more difficult: golang/go#17108

[vburenin]

That is definitely a lot of work. I would not go that far unless it is really needed.

[nkovacs]

I ran into this while fixing #3, but by just ignoring the files that don't contain methods, this error becomes much less likely to occur. I think it's reasonable to require those files to have consistent imports, and you get warnings if you make a mistake. That's a good enough solution for me.