Codegen ICE/regression with 2019-06-12 nightly when using async fn<T: Fn()>(&self, T) #61793
Assignees
Labels
A-async-await
Area: Async & Await
AsyncAwait-Polish
Async-await issues that are part of the "polish" area
C-bug
Category: This is a bug.
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
Matthias247
changed the title
jonas-schievink
added
A-async-await
|
@Matthias247 Could you please test your code out with |
|
I tried running that over the afternoon. Unfortunately something went wrong: Unfortunately that happened after around 1.5 hours of compilation. This machine here is definitely too slow for doing any reasonable rustc compilation :'( |
|
Got it running by deleting enough libraries and rebuilding. Unfortunately it just prints exactly the same error message. I think the setting might already had been enabled as far as I can derive from the compiler output above:
|
Matthias247
changed the title
|
I played around with my code and deleted stuff until I got a simple repro: #![feature(async_await)]
struct Foo {
}
impl Foo {
pub async fn do_foo<F: Fn()>(&self, _f: F) {
}
}
async fn x() {
let foo = Foo{};
foo.do_foo(||{ }).await;
}
fn main() {
let _fut = x();
}It seems like the combination of the member function together with the closure parameter might be the culprit. A top level This also crashes if fn x() {
let foo = Foo{};
foo.do_foo(||{ });
} |
Matthias247
changed the title
|
Reduction of #![feature(async_await)]
#![allow(unused)]
async fn foo<F>(_: &(), _: F) {}
fn main() {
async {
foo(&(), || {}).await;
};
}Reduction of non- #![feature(async_await)]
#![allow(unused)]
async fn foo<F>(_: &(), _: F) {}
fn main() {
foo(&(), || {});
} |
|
@Centril Note that you only need |
|
triage: leaving unprioritized; assigning to @nikomatsakis with intent that they attach priority label as well as any Async-Await specific labels. Leaving nomination tag but hoping I'll remember to skip over it at this week's meeting. |
|
Hi, any temporally way to check on this? My build for tests (just build, just tests) have been failed for days and I have no idea which part of my code caused this in a large code base. |
|
I also see this in my project. I built my own compiler with |
|
I've been investigating, and I believe this is caused by a subtle bug in #60187. (EDIT: In short, we weren't listing ZST fields at the beginning of the layout anymore.) The reason @Matthias247 didn't reproduce in their checkout of the branch is likely that the bug didn't show up until one of the last changes I made to the branch, responding to final review feedback before merging. Working on a fix and will have it up soon with more details. |
|
Opened #62011. |
cramertj
added
AsyncAwait-Polish
tmandry
added a commit
to tmandry/rust
that referenced
this issue
Jun 21, 2019
bors
added a commit
that referenced
this issue
Jun 26, 2019
rustc: correctly transform memory_index mappings for generators. Fixes #61793, closes #62011 (previous attempt at fixing #61793). During #60187, I made the mistake of suggesting that the (re-)computation of `memory_index` in `ty::layout`, after generator-specific logic split/recombined fields, be done off of the `offsets` of those fields (which needed to be computed anyway), as opposed to the `memory_index`. `memory_index` maps each field to its in-memory order index, which ranges over the same `0..n` values as the fields themselves, making it a bijective mapping, and more specifically a permutation (indeed, it's the permutation resulting from field reordering optimizations). Each field has an unique "memory index", meaning a sort based on them, even an unstable one, will not put them in the wrong order. But offsets don't have that property, because of ZSTs (which do not increase the offset), so sorting based on the offset of fields alone can (and did) result in wrong orders. Instead of going back to sorting based on (slices/subsets of) `memory_index`, or special-casing ZSTs to make sorting based on offsets produce the right results (presumably), as #62011 does, I opted to drop sorting altogether and focus on `O(n)` operations involving *permutations*: * a permutation is easily inverted (see the `invert_mapping` `fn`) * an `inverse_memory_index` was already employed in other parts of the `ty::layout` code (that is, a mapping from memory order to field indices) * inverting twice produces the original permutation, so you can invert, modify, and invert again, if it's easier to modify the inverse mapping than the direct one * you can modify/remove elements in a permutation, as long as the result remains dense (i.e. using every integer in `0..len`, without gaps) * for splitting a `0..n` permutation into disjoint `0..x` and `x..n` ranges, you can pick the elements based on a `i < x` / `i >= x` predicate, and for the latter, also subtract `x` to compact the range to `0..n-x` * in the general case, for taking an arbitrary subset of the permutation, you need a renumbering from that subset to a dense `0..subset.len()` - but notably, this is still `O(n)`! * you can merge permutations, as long as the result remains disjoint (i.e. each element is unique) * for concatenating two `0..n` and `0..m` permutations, you can renumber the elements in the latter to `n..n+m` * some of these operations can be combined, and an inverse mapping (be it a permutation or not) can still be used instead of a forward one by changing the "domain" of the loop performing the operation I wish I had a nicer / more mathematical description of the recombinations involved, but my focus was to fix the bug (in a way which preserves information more directly than sorting would), so I may have missed potential changes in the surrounding generator layout code, that would make this all more straight-forward. r? @tmandry
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Unfortunately the error message is super thin and I can't provide the source of the project. Therefore it's also hard to provide a minimal reproducible example.
Some hints:
The text was updated successfully, but these errors were encountered: