feat: add full_name callback to proto messages

[yordis]

closes #408

[yordis]

It seems that full_name could be deterministic at compile time

syntax = "proto3";
package demo.v1;

import "google/protobuf/any.proto";

message Example {
  message NestedFirstLevel {
    message NestedSecondLevel {}

    NestedSecondLevel nested_second = 1;
  }

  enum NestedTypes {
    TYPE_UNSPECIFIED = 0;
    TYPE_ONE = 1;
    TYPE_TWO = 2;
  }

  NestedFirstLevel nested_first = 1;
  NestedTypes type = 2;
}

enum TopLevelEnum {
  TOP_LEVEL_UNSPECIFIED = 0;
  TOP_LEVEL_ONE = 1;
  TOP_LEVEL_TWO = 2;
}

message Integration {
  google.protobuf.Any data = 1;
}

package demo__test

import (
	"fmt"
	"github.com/stretchr/testify/assert"
	"google.golang.org/protobuf/reflect/protoreflect"
	"testing"
	demov1 "demo/gen/pb/demo/v1"
)

func TestName(t *testing.T) {
	nestedFirstNestedSecond := &demov1.Example_NestedFirstLevel_NestedSecondLevel{}
	nestedFirst := &demov1.Example_NestedFirstLevel{NestedSecond: nestedFirstNestedSecond}
	example := demov1.Example{NestedFirst: nestedFirst}

	exampleName := fullName(&example)
	fmt.Printf("%v", exampleName)

	nestedFirstName := fullName(example.GetNestedFirst())
	nestedFirstNameTop := fullName(nestedFirst)
	fmt.Printf("%v  --- %v", nestedFirstName, nestedFirstNameTop)
	assert.Equal(t, nestedFirstName, nestedFirstNameTop)

	nestedFirstNestedSecondName := fullName(example.GetNestedFirst().GetNestedSecond())
	nestedFirstNestedSecondNameTop := fullName(nestedFirstNestedSecond)
	fmt.Printf("%v --- %v", nestedFirstNestedSecondName, nestedFirstNestedSecondNameTop)
	assert.Equal(t, nestedFirstNestedSecondName, nestedFirstNestedSecondNameTop)
}

func fullName(msg protoreflect.ProtoMessage) protoreflect.FullName {
	return msg.ProtoReflect().Descriptor().FullName()
}

[yordis]

It seems that Golang does not allow me pass enum values to anypkg, so I think that such full_name isn't in there for the enum values since it always exists inside a message as a type

[yordis]

https://protobuf.com/docs/language-spec#fully-qualified-names

[yordis]

@whatyouhide @v0idpwn I think it is ready to code review, at least adding the fallback to follow up on Any type

[yordis]

As far as I can tell package is technically required, a lot of test cases where such information is missing, I wonder if that should be fixed

[yordis]

** (RuntimeError) reading from :stdio failed: {:error, {:no_translation, :unicode, :latin1}}

What in the world is that 🤔

[whatyouhide]

Mh yeah, I have very vague memories of this but no notes on it, sorry 😭 I don't really have cycles to look into this now :(

[sindrip]

Hi @yordis I'm familiar with this error, it is something that came in OTP 26, there is good context here with a fix and a link to the issue in OTP: https://elixirforum.com/t/apparent-regression-reading-binary-data-from-stdio-in-erlang-26/57111/3

If you are simply looking for a way to get CI to pass, this is one way to do it: sindrip@f99091d

    env:
      MIX_ENV: test
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      # Set locale to handle encoding issues in newer Elixir versions
      LC_ALL: C.UTF-8
      LANG: C.UTF-8
      ERL_AFLAGS: "-kernel standard_io_encoding latin1"

And then you would have to re-generate some files and CI will pass.

Now I have another suggestion, and maybe this is better suited for @whatyouhide or @v0idpwn but there seems to be a way to pass this to the generated escript, as I do need to pass these kernel encoding flags to a lot of generation scripts that I use at work which is tedious.

And that could be done maybe like this: sindrip@7c4f3f1

  defp escript do
    [
      main_module: Protobuf.Protoc.CLI,
      name: "protoc-gen-elixir",
      emu_args: emu_args()
    ]
  end

  defp emu_args() do
    case :erlang.system_info(:otp_release) do
      v when v in [~c"26", ~c"27"] -> "-kernel standard_io_encoding latin1"
      _ -> ""
    end
  end

But it is not thoroughly tested (although it also works in CI.)

[yordis]

@sindrip my hero 🦸‍♂️

[yordis]

@v0idpwn @whatyouhide IT IS PASSING!!!!!!!!!! I am so happy right now

[georgecoss]

thank you for helping to work toward supporting grpc error details in elixir!

[whatyouhide]

Awesome job, thank you @yordis 🫶

[yordis]

Hey @whatyouhide do you think it is possible to cut a release for this feature, and #422