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

Block more things #1469

Merged
merged 2 commits into from
Sep 25, 2023
Merged

Block more things #1469

merged 2 commits into from
Sep 25, 2023

Conversation

thomasvl
Copy link
Collaborator

So if one tries to move say Sendable off the generated extension [MessageName] and declare it when the struct is declare, then things go comically wrong as the compiler decides we're trying to say all the other structs try to use the local version of Sendable which is another struct. And trying to scope it as Swift.Sendable also fails, because the locally defined Swift gets in the way.

I guess no one has ever really hit this in the field, but it seems better to play it safe and force any attempt to use these as type should get them remapped to avoid the potential confusion they will create.

I'm sorta surprised the generated_names have worked up until now; but play is
safe and ensure we never generate a struct (message) or enum (enum or oneof)
with some of the common things used in conformances or for scoping symbols, as
when it goes wrong, things are very confusing.
Copy link
Contributor

@tbkka tbkka left a comment

Choose a reason for hiding this comment

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

Good catch! FWIW, I think this is fine for 1.x.

@thomasvl thomasvl merged commit eebfda3 into apple:main Sep 25, 2023
9 checks passed
@thomasvl thomasvl deleted the block_more_things branch September 25, 2023 21:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants