+
Skip to content

Remove #[non_exhaustive] from read::CallFrameInstruction #764

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

Merged
merged 1 commit into from
Jun 1, 2025

Conversation

gtsiam
Copy link
Contributor

@gtsiam gtsiam commented May 29, 2025

Using #[non_exhaustive] disallows users of the library from exhaustively matching the enum. This is nice for semver, but terrible for library users who are now in the awkward position of having to remember to update their exhaustive match when updating gimli.

This is less than ideal. I would know, as I now have to deal with it.

PS: RegisterRule is also highly suspect, but as it hasn't yet created problems (for me at least), so I'll leave it be for now.

@bjorn3
Copy link
Contributor

bjorn3 commented May 29, 2025

The non_exhaustive_omitted_patterns lint exists for precisely this reason. Unfortunately it is still unstable though.

Using #[non_exhaustive] disallows users of the library from exhaustively
matching the enum. This is nice for semver, but terrible for library
users who are now in the awkward position of having to remember to
update their exhaustive match when updating gimli.

This is less than ideal. I would know, as I now have to deal with it.
@gtsiam gtsiam force-pushed the exhaustive-instr branch from ec70adf to 9aa22e0 Compare May 29, 2025 19:02
@gtsiam gtsiam changed the title Remove #[non_exhaustive] from CallFrameInstruction Remove #[non_exhaustive] from read::CallFrameInstruction May 29, 2025
@gtsiam gtsiam requested a review from bjorn3 June 1, 2025 10:02
Copy link
Collaborator

@philipc philipc left a comment

Choose a reason for hiding this comment

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

Thanks!

Yes, this is fine. There are many other similar enums for which this crate doesn't have this attribute, so it doesn't make sense to single this out (and I would be fine with RegisterRule and write::CallFrameInstruction if someone wanted it).

There are also a few other enums where do we have non_exhaustive but I think those ones make sense to have.

@philipc philipc merged commit c2e0ec1 into gimli-rs:master Jun 1, 2025
20 checks passed
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.

3 participants
点击 这是indexloc提供的php浏览器服务,不要输入任何密码和下载