fix: include nested enums in parent message file instead of separate files

[yordis]

Problem

When two messages in the same package each define a nested enum with the same local name (e.g. both ListFoosRequest and ListBarsRequest have a nested SortOrder enum), the builder was emitting a separate top-level synthetic file for each nested enum:

• pkg.ListFoosRequest.SortOrder.proto → top-level enum SortOrder
• pkg.ListBarsRequest.SortOrder.proto → top-level enum SortOrder

Both files are in the same package with the same top-level symbol (SORT_ORDER_UNSPECIFIED). gRPC reflection clients that pass the resulting FileDescriptorSet through protodesc.NewFiles() (e.g. k6) fail with:

proto: file "pkg.ListBarsRequest.SortOrder.proto" has a name conflict
over pkg.SORT_ORDER_UNSPECIFIED

This was reported in grafana/k6#5712.

Root Cause

Util.get_nested_types/3 only walked nested_type (nested messages) in a DescriptorProto, not enum_type (nested enums). So when the builder encountered a field referencing a nested enum, it did not recognise it as belonging to the parent message and created a standalone synthetic file for it instead.

Fix

Extend get_nested_types/3 to also collect enum_type symbols from the DescriptorProto. Nested enum symbols are now included in the "nested types" set, so the builder correctly keeps them inside their parent message's file.

Tests

• Added priv/protos/nested_enum_conflict.proto — a service with two messages in the same package each having a nested SortOrder enum (the minimal repro case).
• Added a failing test does not produce top-level enum files for nested enums with the same name in builder_test.exs that asserts the nested enum files are not emitted as separate top-level files.
• All 59 existing tests continue to pass.

[yordis]

Since I also worked on it, protoc_gen_elixir_version >= 0.16 includes the full name that could be leverage as well

[mjheilmann]

LGTM, thanks for the related test coverage

[yordis]

@mjheilmann should the pkg take advantage of latest protoc generation?

[mjheilmann]

@yordis i don't see why not.

Looking at https://endoflife.date/erlang and the warning from the google grpc dep the Elixir and OTP versions I pinned for development are stale too.

While my employer uses this lib, I don't anymore, so I'm not as quick to find issues myself. If you see problems or useful improvements feel free to make PRs or even just create issues. It's not a problem at all for me, I welcome it.