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

Use feature cfg outside macro #27

Closed
wants to merge 2 commits into from

Conversation

dschatzberg
Copy link

cfg(feature="nightly") was being evaluated within the crate using the
lazy_static! macro. Instead we generate different macros depending on
the cfg.

@dschatzberg
Copy link
Author

I unfortunately had to mark the second doctest as ignore, it fails without the const_fn feature flag but I have no way to access the "nightly" feature flag from within the doctest to make it conditional.

cfg(feature="nightly") was being evaluated within the crate using the
lazy_static! macro. Instead we generate different macros depending on
the cfg.

Signed-off-by: Dan Schatzberg <schatzberg.dan@gmail.com>
@durka
Copy link
Contributor

durka commented Feb 1, 2016

I suppose this conflicts with #32. Is it bad for the cfg_attr to be evaluated in the invoking crate? They are going to have to declare the #![feature]s anyway to use the nightly version.

BTW: since rust-lang/rust#30372 was fixed, cfg_attr works fine in doctests.

Now that config attributes can be checked inside doc tests, the nightly
tests will pass.

Signed-off-by: Dan Schatzberg <schatzberg.dan@gmail.com>
@dschatzberg
Copy link
Author

The problem is that the "nightly" config attribute is defined for the lazy-static crate, not the invoking crate. So checking the attribute inside the macro (which is evaluated inside the invoking crate) doesn't make sense. This change uses the attribute to generate a different macro altogether.

Thanks for the note on the doc test. It is now unignored

@durka
Copy link
Contributor

durka commented Feb 2, 2016

Yes, you're right. i guess nobody noticed until now because everyone names their nightly feature "nightly" :)

@durka durka mentioned this pull request Feb 2, 2016
@compressed
Copy link

I'm not sure defining the cfg feature outside the lazy_static! macro is a good idea. If I'm building a crate that needs to support both nightly and stable, I'd like to use the nightly features of the macro if the user of my crate is using nightly. I can do this currently by making a nightly feature in my crate. Users that opt into the nightly feature will gain the benefits of lazy_static's nightly features as well. Granted, there is some coupling with the feature name, but maybe this can just be better documented in lazy_static.

I don't believe we can specify conditional features based upon other features in Cargo.toml... Going with this PR's approach, we'd need something like this for a crate that wants to support both stable and nightly features using lazy_static:

[dependencies]
lazy_static = { version = "..", features = if nightly then ["nightly"] else [] }

[features]
nightly = []

@durka
Copy link
Contributor

durka commented Feb 8, 2016

@compressed actually you can do that:

[dependencies]
lazy_static = "*"

[features]
nightly = ["lazy_static/nightly"]

Documented here but only in the code sample.

@compressed
Copy link

@durka oh awesome, that's perfect then. Yeah, I didn't spot that in the docs when I was going through, thanks!

👍

@Kimundi
Copy link
Contributor

Kimundi commented Apr 13, 2016

Hi, very very sorry for the long delay!

I incorporated the changes here into master. I didn't merge directly due to wanting to incoperate other PR's as well, and they all started to cause merge conflicts with each other. :P

Could you check if I missed something and then close this PR?

Note that current master is not yet a published cargo version since my computer literally broke while preparing the commits for this, and I'm still in the process of recovering.

@dschatzberg
Copy link
Author

Looks good. Thank you! Hope you recover your machine.

@Kimundi
Copy link
Contributor

Kimundi commented Apr 13, 2016

Thanks! Seems to have all worked out so far. I'll publish the changes as v0.2 on crates.io now.

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.

4 participants