Skip to content

LLVM error with trait objects #47638

New issue
New issue
Closed
Closed
LLVM error with trait objects#47638
Assignees
nikomatsakis
Labels
A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.C-bugCategory: This is a bug.P-highHigh priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-betaPerformance or correctness regression from stable to beta.
Milestone
1.24

Description

@matthewjasper
matthewjasper
opened on Jan 21, 2018

The following code

fn id<'c, 'b>(f: &'c &'b Fn(&i32)) -> &'c &'b Fn(&'static i32) {
    f
}

fn main() {
    let f: &Fn(&i32) = &|x| {};
    id(&f);
}

gives the following error on beta (1.24) and nightly (1.25 2018-01-17). It compiles successfully on stable.

Function return type does not match operand type of return inst!
  ret { %"core::ops::function::Fn<(&i32), Output=()>.0"*, {}* }* %3, !dbg !36
 { %"core::ops::function::Fn<(&i32), Output=()>"*, {}* }*LLVM ERROR: Broken function found, compilation aborted!

Activity

  1. Imagedtolnay
    added
    regression-from-stable-to-betaPerformance or correctness regression from stable to beta.
    A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    on Jan 21, 2018

  2. dtolnay commented on Jan 21, 2018

    @dtolnay
    dtolnay
    on Jan 21, 2018
    Member

    Mentioning @michaelwoerister @eddyb @nagisa who touched librustc_trans recently (disclaimer: I don't know if that's where this problem would come from but it sounds relevant).

  3. Imageemilyalbini
    added this to the 1.24 milestone on Jan 21, 2018

  4. eddyb commented on Jan 21, 2018

    @eddyb
    eddyb
    on Jan 21, 2018
    Contributor

    cc @pnkfelix @nikomatsakis Is this one of those "HRTB lifetimes in rustc_trans causes distinct LLVM types" bugs? It seems like there's two distinct types for the unsized pointee of Fn(&i32).

  5. ImageTimNN
    added
    C-bugCategory: This is a bug.
    on Jan 23, 2018
  6. Imagenikomatsakis
    self-assigned this
    on Jan 25, 2018

  7. nikomatsakis commented on Jan 25, 2018

    @nikomatsakis
    nikomatsakis
    on Jan 25, 2018
    Contributor

    triage: P-high

    We need to figure this out.

  8. Imagerust-highfive
    added
    P-highHigh priority
    on Jan 25, 2018

  9. ritiek commented on Jan 27, 2018

    @ritiek
    ritiek
    on Jan 27, 2018
    Contributor

    So, I was testing nightly toolchains and this has been a problem since:

    $ rustc -vV
rustc 1.23.0-nightly (33374fa9d 2017-11-20)
binary: rustc
commit-hash: 33374fa9d09e2a790979b31e61100dfed4b44139
commit-date: 2017-11-20
host: x86_64-unknown-linux-gnu
release: 1.23.0-nightly
LLVM version: 4.0

    The code compiles OK with previous day's nightly:

    $ rustc -vV
rustc 1.23.0-nightly (5041b3bb3 2017-11-19)
binary: rustc
commit-hash: 5041b3bb3d953a14f32b15d1e41341c629acae12
commit-date: 2017-11-19
host: x86_64-unknown-linux-gnu
release: 1.23.0-nightly
LLVM version: 4.0

  10. dtolnay commented on Jan 27, 2018

    @dtolnay
    dtolnay
    on Jan 27, 2018
    Member

    5041b3b...33374fa then, almost certainly something in #45225. @eddyb

  11. eddyb commented on Jan 27, 2018

    @eddyb
    eddyb
    on Jan 27, 2018
    Contributor

    @dtolnay I introduced it for this specific case, yeah, but it's a long-standing bug AFAICT (#36744).
    We have some hacks when doing stores and calls, at least, but it's not ideal.
    I'm hoping @nikomatsakis can confirm and knows of a better direction for #36744.

  12. nikomatsakis commented on Jan 30, 2018

    @nikomatsakis
    nikomatsakis
    on Jan 30, 2018
    Contributor

    So I agree with @eddyb that it's the same bug. I think my preferred longer term fix is to change our rules around subtyping and higher-ranked regions -- but in the short term, I suspect we need some bit casts.

  13. eddyb commented on Jan 30, 2018

    @eddyb
    eddyb
    on Jan 30, 2018
    Contributor

    This is not a new regression in its general case, only specifically trait objects outside of structs:

    struct Newtype<T>(T);

fn id<'c, 'b>(f: &'c Newtype<&'b Fn(&i32)>) -> &'c Newtype<&'b Fn(&'static i32)> {
    f
}

fn main() {
    let f: &Fn(&i32) = &|x| {};
    id(&Newtype(f));
}

    This fails with the LLVM error in 1.0 through 1.22, according to godbolt.
    Somehow, #45225 (presumably) fixed that and introduced a different form of it.

  14. Imagekennytm
    added a commit that references this issue on Jan 31, 2018

    Rollup merge of rust-lang#47891 - eddyb:issue-47638, r=nikomatsakis

    bacb5b7
  15. Imagebors
    closed this as completedin #47891on Jan 31, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.C-bugCategory: This is a bug.P-highHigh priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-betaPerformance or correctness regression from stable to beta.

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions