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

Functions/modules using unstable *syntax* (e.g., impl Trait) can't be CFGed out on stable #36478

Closed
Stebalien opened this issue Sep 14, 2016 · 5 comments · Fixed by #36482
Closed

Comments

@Stebalien
Copy link
Contributor

This fails on stable because rust still parses the unstable module:

#[cfg(feature = "unstable")]
mod unstable {
    fn foo() -> impl Foo {}
}

It's possible to work around this by conditionally defining a macro and then having the macro define the module but that's a bit messy:

#[cfg(feature = "unstable")]
macro_rules! decl_unstable {
    () =>  {
        mod unstable {
            fn foo() -> impl Foo {}
        }
    }
}

#[cfg(not(feature = "unstable"))]
macro_rules! decl_unstable {
    () =>  {}
}

decl_unstable!();
@durka
Copy link
Contributor

durka commented Sep 14, 2016

Or implement the module in another file. I think this is a fundamental limitation -- you can't skip forward over an item if you don't understand the syntax that the item is using. The only way we could solve it is with time travel, i.e., doing a point release of stable that knows the impl Trait syntax but not what it means.

@Stebalien
Copy link
Contributor Author

Or implement the module in another file.

That's actually what I'm doing in my project (still the same problem). That is, I have the following in my lib.rs:

#[cfg(feature="unstable")]
mod unstable;

And a module, unstable.rs

fn foo() -> impl Foo {}

@retep998
Copy link
Member

retep998 commented Sep 14, 2016

Modules are parsed before #[cfg]'s are parsed, which has been an issue for as long as I can remember. Can someone find whether there is an issue tracking this?

@durka
Copy link
Contributor

durka commented Sep 14, 2016

Dupe of #27873. cc @jseyfried (cfg expert!)

@durka
Copy link
Contributor

durka commented Sep 14, 2016

Though this'll be fixed by the above PR, the workaround for current stable is

#[cfg_attr(feature="nightly", path="nightly_stuff.rs")]
#[cfg_attr(not(feature="nightly"), path="stable_stuff.rs")]
mod stuff;

bors added a commit that referenced this issue Sep 17, 2016
…ules, r=nrc

Avoid loading and parsing unconfigured non-inline modules.

For example, `#[cfg(any())] mod foo;` will always compile after this PR, even if `foo.rs` and `foo/mod.rs` do not exist or do not contain valid Rust.

Fixes #36478 and fixes #27873.

r? @nrc
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 a pull request may close this issue.

3 participants