-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Labels
A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.C-bugCategory: This is a bug.Category: This is a bug.P-highHigh priorityHigh priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant 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.Performance or correctness regression from stable to beta.
Milestone
Description
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!
Metadata
Metadata
Assignees
Labels
A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.C-bugCategory: This is a bug.Category: This is a bug.P-highHigh priorityHigh priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant 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.Performance or correctness regression from stable to beta.
Type
Projects
Relationships
Development
Select code repository
Activity
dtolnay commentedon Jan 21, 2018
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).
eddyb commentedon Jan 21, 2018
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 ofFn(&i32)
.nikomatsakis commentedon Jan 25, 2018
triage: P-high
We need to figure this out.
ritiek commentedon Jan 27, 2018
So, I was testing nightly toolchains and this has been a problem since:
The code compiles OK with previous day's nightly:
dtolnay commentedon Jan 27, 2018
5041b3b...33374fa then, almost certainly something in #45225. @eddyb
eddyb commentedon Jan 27, 2018
@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.
nikomatsakis commentedon Jan 30, 2018
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.
eddyb commentedon Jan 30, 2018
This is not a new regression in its general case, only specifically trait objects outside of structs:
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.
4 remaining items