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

Using storage_types macro requires defining crate features #61

Closed
Nemo157 opened this issue Mar 29, 2018 · 3 comments
Closed

Using storage_types macro requires defining crate features #61

Nemo157 opened this issue Mar 29, 2018 · 3 comments

Comments

@Nemo157
Copy link
Contributor

Nemo157 commented Mar 29, 2018

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 calling storage_types!, not the features of uom.

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?

@iliekturtles
Copy link
Owner

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 #cfg attributes out of the match bodies and on to match arms. Not sure if this will work for sure but this may make the #cfg attributes apply in the uom crate before the macro is executed by the calling crate.

@Nemo157
Copy link
Contributor Author

Nemo157 commented Mar 30, 2018

A possible solution without Macros 2.0 is to move #cfg attributes out of the match bodies and on to match arms.

That was my first thought, but it doesn't look like macro_rules! allows attributes on the match arms.

@Nemo157
Copy link
Contributor Author

Nemo157 commented Mar 31, 2018

I think it's actually the modularization changes for Macros 2.0 that would easily allow fixing this, the helper arms of the storage_types! macro could be split out into separate macros that could then be cfged out, e.g. somewhat like

#[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 storage_types! could then delegate to hygienically.

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 macro_rules!.

Nemo157 added a commit to Nemo157/uom that referenced this issue Apr 12, 2018
Allows separately enabling them based on features, at the cost of extra
code and macro name pollution.

Fixes iliekturtles#61 without tests coverage
Nemo157 added a commit to Nemo157/uom that referenced this issue Apr 12, 2018
Allows separately enabling them based on features, at the cost of extra
code and macro name pollution.

Fixes iliekturtles#61 without test coverage
iliekturtles added a commit that referenced this issue Apr 16, 2018
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.
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

No branches or pull requests

2 participants