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

Add custom attributes for States and Events enum #88

Merged
merged 4 commits into from
Aug 19, 2024

Conversation

prabhpreet
Copy link
Contributor

Use states_attr and events_attr to add custom attributes (eg. #[allow(...)])

Example:

#![deny(non_camel_case_types)]
    statemachine! {
        transitions: {
            *State1 + tostate2 = State2,
            State2 + tostate3 / increment_count = State3
        },
        derive_states: [Debug, Clone, Copy],
        states_attr: #[non_exhaustive] #[repr(u8)],
        events_attr: #[derive(Debug)] #[allow(non_camel_case_types)]
    }

Use `states_attr` and `events_attr` to add custom attributes (eg. #[allow(...)])
Copy link
Collaborator

@ryan-summers ryan-summers left a comment

Choose a reason for hiding this comment

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

I would prefer if we just completely replaced the derive_* fields and replaced them with these *_attributes fields instead. Having them spread across different implementations seems messy.

Alternatively, are there some common-sense attributes that you think should be applied to states/events?

@prabhpreet
Copy link
Contributor Author

I would prefer if we just completely replaced the derive_* fields and replaced them with these *_attributes fields instead. Having them spread across different implementations seems messy.

I agree this is better, I'll remove the derive_* fields, will be a breaking change

Alternatively, are there some common-sense attributes that you think should be applied to states/events?

My motivation was to customize the structs when serializing using serde. Since this is also targeted towards no_std, maybe it is better for the users to decide?

@ryan-summers
Copy link
Collaborator

Breaking changes are fine. We've done lots of them recently, and I try to release as often as required :) The migration tends to be quite easy.

@prabhpreet
Copy link
Contributor Author

@ryan-summers Made the changes including tests, and docs, please feel free to review/edit

Copy link
Collaborator

@ryan-summers ryan-summers left a comment

Choose a reason for hiding this comment

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

Mind just updating the changelog and addressing CI (clippy)? Looks like a nice clean change set - nice work :)

@ryan-summers ryan-summers merged commit e1ba392 into korken89:master Aug 19, 2024
6 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.

2 participants