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.
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.