Comparing v0.5.0...v0.5.1 · uber-go/mock (original) (raw)

Commits on Oct 17, 2024

1. Configuration menu
   Browse the repository at this point in the history

Commits on Oct 28, 2024

1. Package Mode: Use aliases when used in source (#220)
   v0.5.0 included #207, which replaced reflect mode with package mode. One
   issue with package mode that came up (ref: #216) was that generated
   mocks for interfaces that referred to alias types were referring to the
   aliases' underlying names instead.
   e.g.,
   some package:

package somgpkg  
import "somepkg/internal/apicodec"  
...  
type Codec = apicodec.Codec  

mockgen input:

type Foo interface{  
    Bar() somepkg.Codec  
}  

mock:

func (m *MockFoo) Bar() apicodec.Codec { // This is a problem, since apicodec is an internal package.  
    // ...  
}  

While technically this problem is solved in Go 1.23 with explicit alias
types representation, (indeed, if you run mockgen on the example in the
linked issue with GODEBUG=gotypesalias=1, you get the expected
behavior) since we support the last two versions, we can't bump go.mod
to 1.23 yet. This leaves us with the old behavior, where go/types does
not track alias types. You can tell if an object is an alias, but not a
type itself, and there is no way to retrieve the object of interest at
the point where we are recursively parsing method types.
This PR works around this issue (temporarily) by using syntax
information to find all references to aliases in the source package.
When we find one, we record it in a mapping of underlying type -> alias
name. Later, while we parse the type tree, we replace any underlying
types in the mapping with their alias names.
The unexpected side effect of this is that all references to the
underlying type in the generated mocks will be replaced with the alias,
even if the source used the underlying name. This is fine because:

• If the alias is in the mapping, it was used at least once, which means
  its accessible.
• From a type-checking perspective, aliases and their underlying types
  are equivalent.
  The nice exception to the side effect is when we explicitly request mock
  generation for an alias type, since at that point we are dealing with
  the object, not the type.
  With this PR, the mocks get generated correctly now:

func (m *MockFoo) Bar() Codec {  
    // ...  
}  

Once we can bump go.mod to 1.23, we should definitely remove this,
since the new type alias type nodes solve this problem automatically.

Configuration menu
Browse the repository at this point in the history 2. fix: import and arg collision (#219)
This PR fixes an issue where if the name of an argument to a method that is being mocked collides with the name of a package that needs to be imported, mockgen could generate uncompilable code.
Resolves #218

Configuration menu
Browse the repository at this point in the history

Commits on Nov 19, 2024

1. Fix [-imports](/uber-go/mock/commit/d97cf0dd184941a8f5b8837cd7dfb6a56450aa64) handling aliased imports in source mode (#165)
   In source mode, when generating a mock within the same package that uses
   names from a package that is imported with an alias, the generated mock
   should obey -imports properly and generate imports with the provided
   alias.
   If the generated code is not using the same aliases as the main filed in
   a package the go compiler will still happily run but if you want ot use
   this package as a source in another package where you want to generate a
   mock, mock will fail because it will not know what to do with a package
   that is imported with two different names in a source package.
   This patch fixes the generation by making -imports handling do a more
   correct thing.
   It can be argued that the correct behavior is, by default use the the
   same package aliases as the ones in the source file, however that change
   looked way more invasive and i didn't see a good coverage of tests that
   would help me make sure the changes worked well.
   This is what i found to be the least invasive fix for #166.
   
   Configuration menu
   Browse the repository at this point in the history

Commits on Feb 4, 2025

1. Copying gomock definition and tests from rules_go (#231)
   This PR copies the gomock definition and tests from rules_go with
   minimal changes:

• Replacing github.com/golang/mock with go.uber.org/mock
• Replacing load statements accordingly
• Setting up a Bazel and a Go module in the "bazel" directory
  Note that the Go module uses v0.4.0 of go.uber.org/mock, because the
  latest version is no longer compatible with the gomock rule
  (bazel-contrib/rules_go#4153). We will update
  the rule and mockgen version in subsequent PRs.
  This is a first step in addressing #225
  
  Configuration menu
  Browse the repository at this point in the history

Commits on Apr 7, 2025

1. Configuration menu
   Browse the repository at this point in the history