-
Notifications
You must be signed in to change notification settings - Fork 97
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
Using storage_types macro requires defining crate features #61
Comments
Good point! I haven't really followed what changes will be happening in Macros 2.0 so I'm not sure if that will have a solution to the issue. As a first step I'll add additional documentation to the macro to mention this limitation (PRs also welcome). A possible solution without Macros 2.0 is to move |
That was my first thought, but it doesn't look like |
I think it's actually the modularization changes for Macros 2.0 that would easily allow fixing this, the helper arms of the #[cfg(feature = "u8")]
macro storage_type_u8($(#[$attr:meta])*) @$M:ident ($($tt:tt)*)) {
storage_type!(@$M $(#[$attr])* u8, u8; $($tt)*);
}
#[cfg(not(feature = "u8"))]
macro storage_type_u8($(#[$attr:meta])*) @$M:ident ($($tt:tt)*)) {
} which Taking another look at the Macros 2.0 tracking issue, it doesn't sound like it's coming anytime soon though. I'm going to have an attempt at coming up with a solution that works with |
Allows separately enabling them based on features, at the cost of extra code and macro name pollution. Fixes iliekturtles#61 without tests coverage
Allows separately enabling them based on features, at the cost of extra code and macro name pollution. Fixes iliekturtles#61 without test coverage
New `feature_check` crate is a non-default member of the workspace and verifies that the `storage_types!` macro expands properly based on `uom`'s features and not features in the calling crate. Part of #61.
storage_types!
uses#[cfg(feature = "u32")]
internally to enable and disable different storage types. Unfortunately this is non-hygenic and depends on the features of the crate callingstorage_types!
, not the features ofuom
.The workaround is to just add a default
u32
(or whichever storage type you want) feature to the crate that calls the macro as well.I don't know if there's a simple solution to this problem currently, hopefully Macros 2.0 might allow hygenic
cfg
attributes?The text was updated successfully, but these errors were encountered: