Allow fx.Annotate on In/Out structs with ResultTags/ParamTags, respectively #1053
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…tively. It is currently not possible for fx.Annotate to be used on a function that takes in or returns fx.In and fx.Out structs. This limitation, however, is not necessary when the annotation is different from the struct defined annotations, such as using fx.In with fx.ResultTags Annotation or fx.Out with fx.ParamTags Annotation. This loosens the constraint so that these Annotations become valid. Fixes uber-go#980.
Codecov Report
@@ Coverage Diff @@
## master #1053 +/- ##
=======================================
Coverage 98.52% 98.52%
=======================================
Files 39 39
Lines 2989 2989
=======================================
Hits 2945 2945
Misses 37 37
Partials 7 7
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
r-hang
approved these changes
Mar 10, 2023
|
Should we update the "pre-requisites" section here: https://uber-go.github.io/fx/annotate.html#annotating-a-function ? |
JacobOaks
approved these changes
Mar 10, 2023
Good call. updated. |
sywhang
added a commit
that referenced
this pull request
Apr 18, 2023
In #1053, we eased up the requirement for function signature for applying annotations to allow using In/Out structs with ResultTags/ParamTags. This had an unintended change in behavior where users are now able to use In/Out structs with From/As annotations. For example, the below code used to error out: > type Foo interface { ... } > type Bar struct { ... } // Bar implements Foo > struct Res { > fx.Out > > ABar Bar > } > fx.Annotate( > func() Res { ... }, > fx.As(new(Foo)), > ) Currently the code above applies the As annotation to ABar field and transforms the target function's signature accordingly. However, this was an unintended change in behavior, and we should have a design discussion about whether we actually want this before cutting a new release. Since it will require a breaking change to disable this after a new release is cut, I think the safe approach is to disable this for now and enable it after having decided that this is indeed what we want. Fixes #1060 --------- Co-authored-by: Sung Yoon Whang <sungyoonwhang@gmail.com> Co-authored-by: JacobOaks <jacoboaks.8@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It is currently not possible for fx.Annotate to be used on a function that takes in or returns fx.In and fx.Out structs.
This limitation, however, is not necessary when the annotation is different from the struct defined annotations, such as using fx.In with fx.ResultTags Annotation or fx.Out with fx.ParamTags Annotation.
This loosens the constraint so that these combinations of Annotations become valid.
Fixes #980.