Does not collect plugins defined outside of crate root

[phrohdoh]

Using:

• inventory version 0.1.3 (have ^0.1 defined in my manifest)
• rustc 1.34.0-nightly (b139669f3 2019-02-06)
• cargo 1.34.0-nightly (4e74e2fc0 2019-02-02)

main.rs

pub mod commands; // added `pub` to see if that would change anything, but it didn't

pub struct Command {
    name: &'static str,
}

impl Command {
    pub fn new(name: &'static str) -> Self {
        Self {
            name,
        }
    }
}

inventory::collect!(Command);

// I tested moving the `mod` to here, after the `collect!`, but no dice

inventory::submit! {
    Command::new("barf")
}

fn main() {
    println!("available commands:");

    for cmd in inventory::iter::<Command> {
        println!("  {}", cmd.name);
    }
}

commands/mod.rs

inventory::submit! {
    crate::Command::new("parse")
}

Output is as follows:

available commands:
  barf

[mathstuf]

Hmm. I'm not having issues with my usage of inventory where I definitely register far out of the crate root. If you have other code (say, a function) in commands/mod.rs does it work? If that doesn't work, what if you call that function before iterating?

[caelunshun]

I'm having a similar issue where plugins are only registered if the module they are submitted in has publicly-exposed functions. Is there a fix for this?

(If it's important, I'm running this on Ubuntu. I haven't tried anything yet on Windows.)

[mathstuf]

That may be a limitation of the linker model. I know at least on Mach-O (macOS), statics are not guaranteed to be initialized before a symbol from the object they live in is needed (this affects static builds in particular). Maybe ELF has a similar mode, but it isn't being used here? Feels like more of an LLVM codegen thing to me though.

[dtolnay]

This is fixed in rustc 1.62.0 / inventory 0.3.0.