-
Notifications
You must be signed in to change notification settings - Fork 14
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
Discourage +
string concatenation from FileDescriptors
#239
Open
seanreid-toast
wants to merge
5
commits into
open-toast:main
Choose a base branch
from
seanreid-toast:file_description_string_builder
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Discourage +
string concatenation from FileDescriptors
#239
seanreid-toast
wants to merge
5
commits into
open-toast:main
from
seanreid-toast:file_description_string_builder
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
This reverts commit 7f9f586.
…r of properties, updated file descriptor to be one line
.joinToCode(" +\n") | ||
} | ||
.joinToCode(",\n") | ||
private fun descriptorLines(): CodeBlock { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- This looks a lot like
String.embed
in KotlinPoetUtils. Is that usable here? - If we're just concatenating all the file descriptor parts, is there any need for it to be a list of strings? Should it just return a CodeBlock?
@@ -207,7 +207,11 @@ private class MessageGenerator( | |||
} else { | |||
buildCodeBlock { | |||
add("return \"%L(\" +\n", msg.className.simpleName) | |||
toStringLines(properties).forEach(::add) | |||
if (properties.size < 100) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this getting around a problem? How does this (or its absence) interact with the ktlint
integration we use to clean up generated code?
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.
Why?
Due to a bug in the Kotlin Compiler, there's a high chance of stack overflow with protos medium+ sized protos (example tested: 1 service, ~20 RPCs, ~45 messages). When concatenating using the
+
operator in Kotlin, the complier can throw a stack overflow exception when generating the bytecode.What changed?
This change is simple: it just makes the file descriptors into one long string rather than generating a broken string with
+
concatenation operators. This allows for larger protos before hitting a stack overflow exception.Testing
All existing tests pass, including tests that validate descriptors match between ProtoKt and protobuf-java. Manual testing was conducted locally to verify that the proto that originally exposed this issue still caused a stack overflow on a branch without this change, but does not with this change
New large proto test
There's a new large proto in this PR that has 600 fields. It passes all tests. >600 seems to fail to build with the same stack overflow that started this work in the first place. 600 is significantly larger than was previously supported.