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

Support multiple ResultTags annotations #1225

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

miyamo2
Copy link

@miyamo2 miyamo2 commented Jul 10, 2024

Closes #1210

This commit makes it possible to specify multiple fx.ResultTags annotations in a single fx.Annotate call.

fx.Provide(
    fx.Annotate(
        func() *bytes.Buffer {
            return bytes.NewBuffer([]byte("Hello!"))
        },
        fx.ResultTags(`name:"a"`),
        fx.ResultTags(`name:"b"`),
        fx.ResultTags(`name:"c"`),
    ),
)

Closes uber-go#1210

This commit makes it possible to specify multiple `fx.ResultTags` annotations in a single `fx.Annotate` call.

```go
fx.Provide(
    fx.Annotate(
        func() *bytes.Buffer {
            return bytes.NewBuffer([]byte("Hello!"))
        },
        fx.ResultTags(`name:"a"`),
        fx.ResultTags(`name:"b"`),
        fx.ResultTags(`name:"c"`),
    ),
)
```
@CLAassistant
Copy link

CLAassistant commented Jul 10, 2024

CLA assistant check
All committers have signed the CLA.

Copy link

codecov bot commented Jul 24, 2024

Codecov Report

Attention: Patch coverage is 76.19048% with 15 lines in your changes missing coverage. Please review.

Project coverage is 97.94%. Comparing base (8fa92e9) to head (2218081).
Report is 1 commits behind head on master.

Files Patch % Lines
annotated.go 76.19% 12 Missing and 3 partials ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1225      +/-   ##
==========================================
- Coverage   98.42%   97.94%   -0.49%     
==========================================
  Files          35       35              
  Lines        2918     2965      +47     
==========================================
+ Hits         2872     2904      +32     
- Misses         38       50      +12     
- Partials        8       11       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Contributor

@tchung1118 tchung1118 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for opening up a PR for this. I added a couple of comments to start with.

defer app.RequireStart().RequireStop()
})

t.Run("specify two ResultTags containing multiple tags", func(t *testing.T) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should add a test case for using multiple As annotations and ResultTags annotations. For example, something like the following:

fx.Provide(
    fx.Annotate(
        func() *bytes.Buffer { return bytes.NewBuffer() },
        fx.As(new(io.Reader)),
        fx.As(new(io.Writer)),
        fx.ResultTags(`name:"foo"`),
        fx.ResultTags(`name:"bar"`),
    )
)

In fact, what's the expected behavior in this case?
I think the current implementation will produce 4 results from the above code, right? But does that make sense? Does "using multiple ResultTags annotation" only make sense when there is 0 or 1 As annotation? If so, we should probably add additional logic to validate that to apply() method of resultTagsAnnotation.

)

newOut.Fields = []reflect.StructField{_outAnnotationField}
newOut.Offsets = []int{}
// to prevent duplicate applying of the same tag to the same type, it is kept in the following format
// {"foo": {"fmt.Stringer": struct{}{}, "myStringer": struct{}{}}, "bar": {"fmt.Stringer": struct{}{}}}
retaggedTypeMap := map[string]map[string]struct{}{}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we validate whether or not a given set of ResultTags annotations will provide conflicting types to the container before we try to build out an actual constructor? (in apply() method) If we validate it beforehand, we won't have to worry about this at all here.

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

Successfully merging this pull request may close these issues.

Support multiple ResultTags annotations
3 participants