uber-go / cadence-client

Describe the bug
go.uber.org/cadence/client/client.go imports go.uber.org/cadence/workflow, whose package name is "workflow". There are also interfaces with parameter named "workflow", which would shadow the imported package "workflow":

cadence-client/client/client.go

Line 85 in 04ccee6

    
           StartWorkflow(ctx context.Context, options StartWorkflowOptions, workflow interface{}, args ...interface{}) (*workflow.Execution, error)

cadence-client/client/client.go

Line 148 in 04ccee6

    
           options StartWorkflowOptions, workflow interface{}, workflowArgs ...interface{}) (*workflow.Execution, error)

It's not a big issue when people are implementing these interfaces, but it becomes a big issue for mockgen to mock these interfaces. In source mode, mockgen would generate functions like:

// SignalWithStartWorkflow mocks base method.
func (m *MockClient) SignalWithStartWorkflow(ctx context.Context, workflowID, signalName string, signalArg interface{}, options client.StartWorkflowOptions, workflow interface{}, workflowArgs ...interface{}) (*workflow.Execution, error) {
	m.ctrl.T.Helper()
	varargs := []interface{}{ctx, workflowID, signalName, signalArg, options, workflow}
	for _, a := range workflowArgs {
		varargs = append(varargs, a)
	}
	ret := m.ctrl.Call(m, "SignalWithStartWorkflow", varargs...)
	ret0, _ := ret[0].(*workflow.Execution)
	ret1, _ := ret[1].(error)
	return ret0, ret1
}

Because workflow is already shadowed by the parameter with type interface{}, *workflow.Execution becomes invalid in the function body.

To Reproduce
Is the issue reproducible?

Yes

Steps to reproduce the behavior:

mockgen -source $GOPATH/src/go.uber.org/cadence/client/client.go > client_mock.go
go build client_mock.go

Expected behavior
Build pass

Additional context
The compilation failed with:

./client_mock.go:49:30: workflow.Execution undefined (type interface {} is interface with no methods)
./client_mock.go:117:30: workflow.Execution undefined (type interface {} is interface with no methods)

Arguably, mockgen should be smart enough to find such shadowing and rename the parameter to avoid the conflict. However, it's not a good idea to require implementer of an interface to rename the parameter.

Parameter names conflicts with package name