Skip to content

Propagate oneofs_nonexhaustive value to descendant contexts #748

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.

Sign up for GitHub

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

Jump to bottom
Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Propagate oneofs_nonexhaustive value to descendant contexts #748

wants to merge 2 commits into from

Conversation

akonradi-signal
Copy link
Contributor

Copy the value of Customize::oneofs_non_exhaustive to the context for fields so that it actually works as expected. Change the code to make it harder to introduce this sort of bug in the future.

Fixes #747

@akonradi-signal
Use destructuring instead of field point access
edcf973 
This ensures that if a new field is added in the future, this code will
be updated to handle it (one way or another), because not doing so will
lead to a compilation error. This will prevent issues like what happened
with oneof_nonexhaustive, where the field was added but its value was
not propagated.
@akonradi-signal
Propagate oneofs_non_exhaustive value
6015b8d 
When constructing Customize instances for fields and inner messages,
propagate the oneofs_non_exhaustive value.
@akonradi-signal
Copy link
Contributor Author

It's worth noting that #726 added a test that didn't actually catch this bug; the test is in theory supposed to fail to compile if the #[non_exhaustive] attribute is present but the author (me) forgot that the attribute only affects usages outside the crate, and the test includes the generated protobuf code as a module, not an external crate. I'd be happy to add a more robust test here, though I'd appreciate some guidance on how to lay that out in the test-crates directory since it requires code that spans at least two crates.

@akonradi-signal akonradi-signal mentioned this pull request Dec 2, 2024
Open
@omerkattan-microsoft
Copy link

@akonradi-signal @stepancheg what is the status of this PR/issue?
I would like to use this feature for exhaustive matching of generated enums which should be safer

@akonradi-signal
Copy link
Contributor Author

I only know what's visible here. This PR is still waiting for review and while I've since lost all context on it the question as to how to structure testing still stands.

@stepancheg
Copy link
Owner

stepancheg commented May 12, 2025 •
edited
Loading

This PR needs some test, which would at least show that some code is generated with these options.

rust-protobuf v3 is barely maintained, and approaching end of line. I don't have a lot of time, so I'm hesitant to work on this PR.

rust-protobuf v4 https://docs.rs/protobuf/4.31.0-rc.2/protobuf/index.html is rewritten from scratch by Google. It does not implement all the features of protobuf, but it is supposed to be more performant and well maintained.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Setting Customize::oneofs_non_exhaustive to false doesn't work
3 participants
@akonradi-signal @omerkattan-microsoft @stepancheg