Undefined reference to `_FILE_LINE`

[panicbit]

Rustc versions: rustc 1.13.0 (2c6933a 2016-11-07) / rustc 1.15.0-nightly (1c44857 2016-11-28)
Cargo versions: cargo 0.13.0-nightly (eca9e15 2016-11-01) / cargo 0.16.0-nightly (3568be9 2016-11-26)
System: Arch Linux x86_64

Compiling my project via cargo test results in a few undefined reference errors:

<project>/<std macros>:2: undefined reference to `flif::image::color_ranges::ColorRanges::snap::_FILE_LINE::hcb541c8d65ccc329'

They seem to correlate to the debug_assert!s in the snap function.
This commit introduced the method and the issue:

https://github.com/panicbit/flif-rs/blob/2494e08cc7be22393948a015615c9b9cfc888014/src/image/color_ranges.rs#L13-L32

I failed to replicate the issue in the playground, so the issue is either related to my system or to something other than the code in the color_ranges.rs. https://is.gd/ytwc2R

Edit:
I created a minimal example https://github.com/panicbit/rust_issue_38226

[alexcrichton]

cc @michaelwoerister, this wouldn't happen to be related to a symbol visibility change recently, would it?

[michaelwoerister]

I'll take a look.

[panicbit]

I created a minimal example https://github.com/panicbit/rust_issue_38226

[michaelwoerister]

It seems that the _FILE_LINE statics in question are not detected by middle::reachable (while other such statics are detected there). So I don't think this was introduced by the symbol visibility changes.

[michaelwoerister]

@panicbit Oh, that's very helpful!

[michaelwoerister]

The minimal example copied inline:

//! The following changes make the issue go away:
//!
//! - Removing type parameters
//! - Removing the let (returning the trait object works!)
//! - Making submod public
//! - Moving SomeTrait to the top-level
//!

pub fn foo<T>() {
    let _: Box<SomeTrait> = Box::new(SomeTraitImpl);
}

mod submod {
    pub trait SomeTrait {
        fn bar(&self) {
            debug_assert!(true);
        }
    }

}

use self::submod::SomeTrait;

pub struct SomeTraitImpl;
impl SomeTrait for SomeTraitImpl {}

[michaelwoerister]

I think what's going on here is that the middle::reachable pass does not detect that let _: Box<SomeTrait> = Box::new(SomeTraitImpl); leads to a vtable SomeTrait for SomeTraitImpl being generated, which in turn makes <SomeTraitImpl as SomeTrait>::bar() reachable.