Closed
Description
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.
thread 'rustc' panicked at 'assertion failed: target_offset >= offset', src/librustc_codegen_llvm/type_of.rs:130:9
stack backtrace:
0: <unknown>
1: <unknown>
2: <unknown>
3: <unknown>
...
36: <unknown>
query stack during panic:
end of query stack
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: rustc 1.37.0-nightly (2887008e0 2019-06-12) running on x86_64-apple-darwin
note: compiler flags: -C debuginfo=2 -C incremental --crate-type bin
note: some of the compiler flags provided by cargo are hidden
Some hints:
- Yesterdays nightly (nightly-2019-06-11-x86_64-apple-darwin) doesn't ICE
- The project makes heavy use of async/await. Therefore it might by related to that. I wondered whether it's about @tmandry's generator optimization from Generator optimization: Overlap locals that never have storage live at the same time #60187. However I also checked that out locally from their branch 2 days ago and built it myself, and it didn't crash. At that point I had all commits up to "Extract generator_layout as a method" included, only the last commit which was added later was missing.
Activity
[-]ICE/regression with todays nightly[/-][+]Codegen ICE/regression with todays nightly[/+]Centril commentedon Jun 13, 2019
@Matthias247 Could you please test your code out with
debuginfo-level = 2
inconfig.toml
(you'll need to build rustc yourself) and provide the more extensive backtrace?Matthias247 commentedon Jun 14, 2019
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 :'(
Matthias247 commentedon Jun 14, 2019
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:
[-]Codegen ICE/regression with todays nightly[/-][+]Codegen ICE/regression with todays nightly when using async fn<T: Fn()>(&self, T)[/+]Matthias247 commentedon Jun 14, 2019
I played around with my code and deleted stuff until I got a simple repro:
It seems like the combination of the member function together with the closure parameter might be the culprit. A top level
async fn
or a a "static" member function (without&self
) doesn't cause an ICE.This also crashes if
x
is not an async function and thereby noawait
is included at all:[-]Codegen ICE/regression with todays nightly when using async fn<T: Fn()>(&self, T)[/-][+]Codegen ICE/regression with 2019-06-12 nightly when using async fn<T: Fn()>(&self, T)[/+]Centril commentedon Jun 14, 2019
Reduction of
async fn
version:Reduction of non-
async fn
version:eddyb commentedon Jun 20, 2019
@Centril Note that you only need
debuginfo-level = 1
to get the backtrace (2
is much more expensive). Maybe we even have builds with that enabled nowadays? Not sure though.EDIT: also, someone needs to do this on linux, the backtraces are probably broken on macOS.
pnkfelix commentedon Jun 20, 2019
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.
5 remaining items
tmandry commentedon Jun 21, 2019
Opened #62011.
Keep ZSTs at beginning of generator layout fields
Auto merge of #62072 - eddyb:generator-memory-index, r=tmandry