Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disambiguate generated properties in C# #10269

Merged
merged 2 commits into from
Jul 21, 2022

Conversation

jskeet
Copy link
Contributor

@jskeet jskeet commented Jul 19, 2022

No description provided.

Copy link

@amanda-tarafa amanda-tarafa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

if (property_name == descriptor->containing_type()->name()
|| property_name == "Types"
|| property_name == "Descriptor") {
|| property_name == "Descriptor"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe just add everything from System.Object, like GetType, MemberwiseClone I think, etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I forgot GetType and MemberwiseClone for some reason. Will add those tomorrow when I move to a set-based approach.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It turns out GetType and MemberwiseClone are slightly trickier - they currently only generate warnings, not errors, so adding an underscore could be a breaking change in that case. I'm not sure of the best solution for that at the moment. (I'm tempted to go really cautiously here. We haven't heard any reports of those causing problems, so I think I'd prefer to leave them for now.)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, +1 for being cautious.

@jskeet
Copy link
Contributor Author

jskeet commented Jul 20, 2022

Changes since previous review:

  • Added more members to the test proto
  • Used an unordered_set in the implementation

@@ -378,16 +378,32 @@ std::string GetFieldConstantName(const FieldDescriptor* field) {
return GetPropertyName(field) + "FieldNumber";
}

// Names of members declared or overridden in the message.
// Used in GetPropertyName below.
static const auto& reserved_member_names = *new std::unordered_set<std::string>({
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unfortunately, you are doing this at the global scope which leads to issues. You need to do this at function scope

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed, I think - but please check carefully! I'm hoping that by declaring it with the static modifier it's still only going to be initialized on first use rather than on every call, right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

correct

@fowles
Copy link
Contributor

fowles commented Jul 20, 2022

There appear to be a lot of failing checks. Can you rebase onto head?

@jskeet
Copy link
Contributor Author

jskeet commented Jul 20, 2022

Rebased now, but I suspect that wasn't the problem. We'll see what happens...

@fowles
Copy link
Contributor

fowles commented Jul 20, 2022

I agree, but one can hope :)

@jskeet
Copy link
Contributor Author

jskeet commented Jul 20, 2022

Looks like it's now just "all the MacOS tests" that are failing - I don't know enough about MacOS to help on that front :(

jskeet added 2 commits July 21, 2022 14:11
This won't remove all possibilities of naming collisions, but will address the simplest ones.
The "test" is just to add all the reserved names in a proto file: if the generated code builds, it works.
Note that before this change, using any of these field names would result in a compile-time error, so this is not a breaking change.

Generated code is in the next commit.

Fixes protocolbuffers#8810
@jskeet
Copy link
Contributor Author

jskeet commented Jul 21, 2022

@fowles: All green now - please merge if you're happy to do so :)

@fowles fowles merged commit 36a92e2 into protocolbuffers:main Jul 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants