Allow using imported types

xitep commented

2016-03-02 14:06:49 -06:00

(Migrated from github.com)

In short, the following should be possible:

extern crate libc;
use libc::c_uint;
mod constants;

bitflags! {
    pub flags EnvFlags: c_uint {
        const EnvNoSync = constants::MDB_NOSYNC,
       // ...
    }
}

As of #38, the above example will not compile. As a workaround, one can reference the imported types/modules within the bitflags definition using absolute paths, e.g. using ::libc::c_uint instead of c_uint or ::constants::MDB_NOSYNC instead of constants::MDB_NOSYNC. This is, at least, surprising.

In short, the following should be possible: ``` extern crate libc; use libc::c_uint; mod constants; bitflags! { pub flags EnvFlags: c_uint { const EnvNoSync = constants::MDB_NOSYNC, // ... } } ``` As of #38, the above example will not compile. As a workaround, one can reference the imported types/modules within the bitflags definition using absolute paths, e.g. using `::libc::c_uint` instead of `c_uint` or `::constants::MDB_NOSYNC` instead of `constants::MDB_NOSYNC`. This is, at least, surprising.

dimbleby commented

2016-03-03 14:52:22 -06:00

(Migrated from github.com)

I've been unable even to find a workaround that will allow an example like this to compile with 0.5.0:

extern crate foo_sys;

bitflags! {
   flags FooFlags: i32 {
        const Flag1 = foo_sys::flag1,
        // ...
    }
}

... as for example here.

Probably I'm missing some incantation. But was it intended that such things should break?

I've been unable even to find a workaround that will allow an example like this to compile with 0.5.0: ``` rust extern crate foo_sys; bitflags! { flags FooFlags: i32 { const Flag1 = foo_sys::flag1, // ... } } ``` ... as for example [here](https://github.com/dimbleby/rust-c-ares/blob/76f1bdd44dcf0ee5497f5a68ecd41bf29701b4ef/src/ni_flags.rs). Probably I'm missing some incantation. But was it intended that such things should break?

alexcrichton commented

2016-03-03 15:23:54 -06:00

(Migrated from github.com)

Right now the workaround is to use absolute paths, but it's unfortunately not great yeah

dimbleby commented

2016-03-03 15:28:58 -06:00

(Migrated from github.com)

But I don't think that this workaround works in this case, does it? Or if you think that it does, could you spell out for me how I can apply it?

Thanks!

But I don't think that this workaround works in this case, does it? Or if you think that it does, could you spell out for me how I can apply it? Thanks!

alexcrichton commented

2016-03-03 15:29:56 -06:00

(Migrated from github.com)

Ah it may not work, I haven't personally tested it myself

xitep commented

2016-03-04 01:24:35 -06:00

(Migrated from github.com)

@dimbleby ... the following works for me:

#[macro_use]
extern crate bitflags;
extern crate liblmdb_sys;

bitflags!(
    pub flags Foo: i32 {
        const ONE = ::liblmdb_sys::MDB_NOTFOUND,
        const TWO = ::liblmdb_sys::MDB_KEYEXIST,
    }
);

fn main() {
    println!("{:?}", ONE | TWO);
}

@dimbleby ... the following works for me: ``` #[macro_use] extern crate bitflags; extern crate liblmdb_sys; bitflags!( pub flags Foo: i32 { const ONE = ::liblmdb_sys::MDB_NOTFOUND, const TWO = ::liblmdb_sys::MDB_KEYEXIST, } ); fn main() { println!("{:?}", ONE | TWO); } ```

dimbleby commented

2016-03-04 03:14:13 -06:00

(Migrated from github.com)

Hmm. When I make the same change in my code (linked above) I get errors like this:

src/ni_flags.rs:7:24: 7:34 error: failed to resolve. Did you mean `self::c_ares_sys`? [E0433]
src/ni_flags.rs:7         const NOFQDN = ::c_ares_sys::ARES_NI_NOFQDN,
                                         ^~~~~~~~~~
<bitflags macros>:139:1: 141:63 note: in this expansion of bitflags! (defined in <bitflags macros>)
src/ni_flags.rs:3:1: 39:3 note: in this expansion of bitflags! (defined in <bitflags macros>)
src/ni_flags.rs:7:24: 7:34 help: run `rustc --explain E0433` to see a detailed explanation
src/ni_flags.rs:7:24: 7:52 error: unresolved name `c_ares_sys::ARES_NI_NOFQDN` [E0425]
src/ni_flags.rs:7         const NOFQDN = ::c_ares_sys::ARES_NI_NOFQDN,
                                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

What's the difference?

Hmm. When I make the same change in my code (linked above) I get errors like this: ``` src/ni_flags.rs:7:24: 7:34 error: failed to resolve. Did you mean `self::c_ares_sys`? [E0433] src/ni_flags.rs:7 const NOFQDN = ::c_ares_sys::ARES_NI_NOFQDN, ^~~~~~~~~~ <bitflags macros>:139:1: 141:63 note: in this expansion of bitflags! (defined in <bitflags macros>) src/ni_flags.rs:3:1: 39:3 note: in this expansion of bitflags! (defined in <bitflags macros>) src/ni_flags.rs:7:24: 7:34 help: run `rustc --explain E0433` to see a detailed explanation src/ni_flags.rs:7:24: 7:52 error: unresolved name `c_ares_sys::ARES_NI_NOFQDN` [E0425] src/ni_flags.rs:7 const NOFQDN = ::c_ares_sys::ARES_NI_NOFQDN, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ ``` What's the difference?

mzabaluev commented

2016-03-06 03:05:14 -06:00

(Migrated from github.com)

I'd rather have this unbroken than enjoy the cosmetic benefits of #14.
But perhaps the implementation in the inner modules could use u64 instead of the parameter type?

I'd rather have this unbroken than enjoy the cosmetic benefits of #14. But perhaps the implementation in the inner modules could use `u64` instead of the parameter type?

mzabaluev commented

2016-03-06 03:10:59 -06:00

(Migrated from github.com)