Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compile error occurs when an arg name is same as a package name. #222

Open
yuzuy opened this issue Oct 30, 2024 · 4 comments
Open

Compile error occurs when an arg name is same as a package name. #222

yuzuy opened this issue Oct 30, 2024 · 4 comments

Comments

@yuzuy
Copy link

yuzuy commented Oct 30, 2024

Actual behavior A clear and concise description of what the bug is.

Compile error occurs when an arg name is same as a package name.

import "github.com/yuzuy/xxx/pagination"

func (m *MockFooUseCase) Exec(ctx context.Context, pagination *pagination.Pagination) (*pagination.Page, error) {
	m.ctrl.T.Helper()
	ret := m.ctrl.Call(m, "Exec", ctx, pagination)
	ret0, _ := ret[0].(*pagination.Page) // pagination.Page is not a type
	ret1, _ := ret[1].(error)
	return ret0, ret1
}

Expected behavior A clear and concise description of what you expected to
happen.

Avoid a conflict between an arg name and a package name.

import "github.com/yuzuy/xxx/pagination"

func (m *MockFooUseCase) Exec(ctx context.Context, paginationArg *pagination.Pagination) (*pagination.Page, error) {
	m.ctrl.T.Helper()
	ret := m.ctrl.Call(m, "Exec", ctx, paginationArg)
	ret0, _ := ret[0].(*pagination.Page)
	ret1, _ := ret[1].(error)
	return ret0, ret1
}

To Reproduce Steps to reproduce the behavior

  • Generate a mock of a method
    • that has an arg with the name that is same as the imported package name
    • that has a return value of the package type

Additional Information

  • gomock mode (reflect or source): reflect
  • gomock version or git ref: v0.5.0
  • golang version: 1.23.1

Triage Notes for the Maintainers

@tompaz3
Copy link

tompaz3 commented Nov 5, 2024

I understand it's the issue for you (and probably for many others), but to be honest, I wouldn't personally introduce package name shadowing in the first place. Shadowing is unsafe on it's own and may lead to bugs eventually.

@rageagainsthepc
Copy link

@tompaz3 I agree, but unfortunately widely used packages like e.g. docker seem to shadow their package names quite often. Right now this probably breaks a lot of projects using mockgen.

@tompaz3
Copy link

tompaz3 commented Nov 5, 2024

@rageagainsthepc Ah, I see. It's still doable, but not without the extra hassle (like replacing it with custom consumer-side interface).
Definitely agree that this is a breaking change, anyway.

@cavus700
Copy link

cavus700 commented Nov 6, 2024

#219 Seems like this will be fixed in the next release

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants