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

Remove inline typeconvert when logging some thrift typedefs #464

Merged
merged 7 commits into from
Feb 18, 2021

Conversation

robbertvanginkel
Copy link
Contributor

#366 added fast zap logging
by generating extra MarshalLog... methods on generated types. For
typedefs in thrift, other types that log them will cast to the
underlying type in their MarshalLog... method, causing the generated
code to need to import multiple go packages generated from both direct
and indirect thrift dependencies.

This should not be necessary, as typedefs of complex types (anything
that cannot be mapped directly to a go stdlb type) get their own
MarshalLog... methods, which cast to underlying type when necessary.

This PR changes the logging for typedef'ed fields to:

  • cast to the underlying type inline when the underlying thrift type
    directly maps to a go type.
  • defer to the typedef's generated MarshalLog... method otherwise.

This results in having more predictable importpaths (eg knowing that one
thrift import will lead to one go import in generated code) makes
implementing good bazel rules for thriftrw easier.

See internal issue GO-362 for a more elaborate example of how the
current behaviour complicates our Bazel setup.

@CLAassistant
Copy link

CLAassistant commented Feb 10, 2021

CLA assistant check
All committers have signed the CLA.

@codecov
Copy link

codecov bot commented Feb 10, 2021

Codecov Report

Merging #464 (12e6b8d) into dev (98f1a23) will increase coverage by 0.03%.
The diff coverage is 87.64%.

Impacted file tree graph

@@            Coverage Diff             @@
##              dev     #464      +/-   ##
==========================================
+ Coverage   78.96%   79.00%   +0.03%     
==========================================
  Files         125      125              
  Lines       15981    16048      +67     
==========================================
+ Hits        12620    12678      +58     
- Misses       2056     2060       +4     
- Partials     1305     1310       +5     
Impacted Files Coverage Δ
gen/generator.go 65.66% <ø> (ø)
gen/zap.go 92.00% <84.61%> (-1.85%) ⬇️
gen/internal/tests/set_to_slice/set_to_slice.go 64.71% <85.71%> (ø)
gen/internal/tests/typedefs/typedefs.go 82.23% <86.66%> (+0.32%) ⬆️
gen/internal/tests/containers/containers.go 70.87% <100.00%> (ø)
gen/internal/tests/structs/structs.go 78.67% <100.00%> (+0.04%) ⬆️
gen/internal/tests/uuid_conflict/uuid_conflict.go 81.17% <100.00%> (ø)
gen/typedef.go 100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 98f1a23...12e6b8d. Read the comment docs.

gen/zap.go Outdated Show resolved Hide resolved
gen/zap.go Outdated Show resolved Hide resolved
gen/zap.go Outdated
// zapTypedefGenerateMarshaler is similar to zapMarshaler but always converts a typedef
// to its root value. This should be used when generating the code for the Zap
// marshal implementation of the typedef.
func (z *zapGenerator) zapTypedefGenerateMarshaler(g Generator, spec compile.TypeSpec, fieldValue string) (string, error) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure why we need this separate function exposed in the template? Looks
like zapMarshaler can (and does) already do this if spec is a
compile.TypedefSpec.

Copy link
Contributor Author

@robbertvanginkel robbertvanginkel Feb 11, 2021

Choose a reason for hiding this comment

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

This zapMarshaler is used in the template that generates MarshalLogObject/MarshalLogArray for typedef, as well as in the template for other object's MarshalLog... function if they have typedef for a field. In the field case you want to not convert to the underlying go type, in the other one you need to typeconvert to the underlying to avoid the typedef's generated MarshalLog... to call itself.

To avoid adding adding an extra parameter to zapMarshaler (something like forceTypedefToRoot bool), I made/exported a new function.

#366 added fast zap logging
by generating extra `MarshalLog...` methods on generated types. For
typedefs in thrift, other types that log them will cast to the
underlying type in their `MarshalLog...` method, causing the generated
code to need to import multiple go packages generated from both direct
and indirect thrift dependencies.

This should not be necessary, as typedefs of complex types (anything
that cannot be mapped directly to a go stdlb type) get their own
`MarshalLog...` methods, which cast to underlying type when necessary.

This PR changes the logging for typedef'ed fields to:
- cast to the underlying type inline when the underlying thrift type
directly maps to a go type.
- defer to the typedef's generated `MarshalLog...` method otherwise.

This results in having more predictable importpaths (eg knowing that one
thrift import will lead to one go import in generated code) makes
implementing good bazel rules for thriftrw easier.

See internal issue GO-362 for a more elaborate example of how the
current behaviour complicates our Bazel setup.
Copy link
Contributor

@abhinav abhinav left a comment

Choose a reason for hiding this comment

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

Mostly LGTM.

To address coverage drop, check out gen/quick_test.go. We need to add newly declared types there.

gen/zap.go Outdated Show resolved Hide resolved
@robbertvanginkel robbertvanginkel merged commit a3e85bd into dev Feb 18, 2021
r-hang pushed a commit that referenced this pull request Feb 18, 2021
#366 added fast zap logging
by generating extra `MarshalLog...` methods on generated types. For
typedefs in thrift, other types that log them will cast to the
underlying type in their `MarshalLog...` method, causing the generated
code to need to import multiple go packages generated from both direct
and indirect thrift dependencies.

This should not be necessary, as typedefs of complex types (anything
that cannot be mapped directly to a go stdlib type) get their own
`MarshalLog...` methods, which cast to underlying type when necessary.

This PR changes the logging for typedef'ed fields to:
- cast to the underlying type inline when the underlying thrift type
directly maps to a go type.
- defer to the typedef's generated `MarshalLog...` method otherwise.

This results in having more predictable importpaths (eg knowing that one
thrift import will lead to one go import in generated code) makes
implementing good bazel rules for thriftrw easier.

See internal issue GO-362 for a more elaborate example of how the
current behaviour complicates our Bazel setup.

Co-authored-by: Abhinav Gupta <abg@uber.com>
@robbertvanginkel robbertvanginkel deleted the robbert/direct-deps branch February 19, 2021 01:04
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

Successfully merging this pull request may close these issues.

4 participants