Skip to content

Undefined reference to _FILE_LINE #38226

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

Closed
panicbit opened this issue Dec 7, 2016 · 7 comments
Closed

Undefined reference to _FILE_LINE #38226

panicbit opened this issue Dec 7, 2016 · 7 comments

Comments

@panicbit
Copy link
Contributor

panicbit commented Dec 7, 2016

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
Copy link
Member

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

@michaelwoerister
Copy link
Member

I'll take a look.

@panicbit
Copy link
Contributor Author

panicbit commented Dec 8, 2016

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

panicbit added a commit to panicbit/flif-rs that referenced this issue Dec 8, 2016
@michaelwoerister
Copy link
Member

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
Copy link
Member

@panicbit Oh, that's very helpful!

@michaelwoerister
Copy link
Member

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
Copy link
Member

michaelwoerister commented Dec 8, 2016

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.

bors added a commit that referenced this issue Dec 11, 2016
…=alexcrichton

Consider provided trait methods in middle::reachable

Fixes #38226 by also considering trait methods with default implementation instead of just methods provided in an impl.

r? @alexcrichton
cc @panicbit
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

No branches or pull requests

3 participants