Discourage + string concatenation from FileDescriptors
#239
Conversation
This file contains hidden or 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.
- This looks a lot like
String.embedin 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?
| buildCodeBlock { | ||
| add("return \"%L(\" +\n", msg.className.simpleName) | ||
| toStringLines(properties).forEach(::add) | ||
| if (properties.size < 100) { |
There was a problem hiding this comment.
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.