Ruby: Add support for proto3 json_name in compiler and field definitions

[lfittl]

This adds support for the json_name field definition, per the Proto3 spec.

Note the JSON output mechanism is already reading the json_name from ubp's struct (see here), but this was not being added to the generated Ruby DSL, or read in from the DSL into the ubp field definitions.

[google-cla]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[lfittl]

@googlebot I signed it!

[lfittl]

@haberman I assume you would be the correct person to review this further?

(Thanks for your work on the Ruby protobuf support!)

[lfittl]

@haberman Ping on this, tagging you since you seem to be the primary maintainer for the Ruby bindings - not sure if I missed anything here. Appreciate the help - thank you :)

[haberman]

Hi @lfittl , I'm sorry for my slow reply on this.

I'm somewhat reluctant to go farther down this path of extending the DSL, because it is an un-winnable game of whack-a-mole. The DSL fundamentally can't represent all options, particular custom options that are used in their own definition:

syntax = "proto3";

import "google/protobuf/descriptor.proto";

extend google.protobuf.FieldOptions {
  optional int32 foo_option = 1000 [(foo_option) = 5];
}

That said, the fact that json_name is a member of FieldDescriptorProto (and not FieldOptions) does make the PR more compatible with a future world where we do handle options correctly. So maybe we can move forward with this now.

[haberman]

I don't think this check should be necessary, upb_fielddef_jsonname() should never return NULL.

[haberman]

I don't follow, if it is a string already why do we need to call to_s on it?

[lfittl]

Yup, you are correct - this was copied from the default value handling above, but json_name is indeed always a string, so this conversion is unnecessary.

[lfittl]

Hi @lfittl , I'm sorry for my slow reply on this.

No worries, I know the same from my own open source projects, thanks for taking a look!

I'm somewhat reluctant to go farther down this path of extending the DSL, because it is an un-winnable game of whack-a-mole. The DSL fundamentally can't represent all options, particular custom options that are used in their own definition:

syntax = "proto3";

import "google/protobuf/descriptor.proto";

extend google.protobuf.FieldOptions {
  optional int32 foo_option = 1000 [(foo_option) = 5];
}

That said, the fact that json_name is a member of FieldDescriptorProto (and not FieldOptions) does make the PR more compatible with a future world where we do handle options correctly. So maybe we can move forward with this now.

Yeah, I see how it's important to handle this generically at some point - but I think it still makes sense to do this now, since it allows use of json_name which seems to me one of the core features of Proto3 (as opposed to other custom field tags).

---

I've addressed the review comments you shared, and also added a test that covers this, to ensure it doesn't break by accident in the future.