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

RFC: condition macro could import parent module's (pub) identifiers #8881

Closed
pnkfelix opened this issue Aug 30, 2013 · 0 comments
Closed

RFC: condition macro could import parent module's (pub) identifiers #8881

pnkfelix opened this issue Aug 30, 2013 · 0 comments
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@pnkfelix
Copy link
Member

Its a little annoying that one has to prefix references to "unusual" types with super:: when using the condition! macro, as demonstrated for example by this code in the conditions tutorial:

// Modify the condition signature to return the new enum.
// Note: a condition introduces a new module, so the enum must be
// named with the `super::` prefix to access it.
condition! {
    pub malformed_line : ~str -> super::MalformedLineFix;
}

The necessity of the super:: prefix is a side-effect of the condition macro expanding into its own module.

But we could get around this if we changed the condition macro to import its parent module's pub declarations, via use super::*;, as illustrated in this code:

pub mod a {
    pub use c_i = std::libc::c_int;

    // condition! { pub grr1: int -> c_i; } // does not work

    condition! {
        pub grr2: int -> super::c_i; // standard way to cope with above
    }

    // but another way to "fix" the problem is to expand into:
    pub mod grr3 {
        #[allow(non_uppercase_statics)];

        use super::*; // <-- THIS LINE IS NEW IN THE EXPANSION

        static key: ::std::local_data::Key<
            @::std::condition::Handler<int, c_i>> =
            &::std::local_data::Key;

        pub static cond :
            ::std::condition::Condition<int,c_i> =
            ::std::condition::Condition {
            name: stringify!(grr3),
            key: key
        };
    }

    pub fn f(x:int) -> c_i {
        if x % 2 == 0 {
            grr2::cond.raise(x)
        } else {
            grr3::cond.raise(x)
        }
    }
}

fn main() {
    use std::libc::c_int;
    let result : c_int = do a::grr3::cond.trap(|whoops| {
        println(fmt!("hi from %?", whoops));
        4 as std::libc::c_int
    }).inside {
        100 + a::f(173)
    };
    println(fmt!("result: %d", result as int));
}
@bors bors closed this as completed in 4a18d46 Sep 4, 2013
flip1995 pushed a commit to flip1995/rust that referenced this issue Jun 4, 2022
Fix imports for "Checking if a type defines a specific method"

The import of `clippy_utils::is_type_diagnostic_item` would cause this error:

```
error[E0432]: unresolved import `clippy_utils::is_type_diagnostic_item
```

changelog: none
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

No branches or pull requests

1 participant