ICE #9400
Comments
|
A gdb backtrace from rust_begin_unwind would be helpful. |
|
Backtrace: https://gist.github.com/jdm/6666205 |
|
I'm seeing the same problem when trying to compile Rust from source on an Ubuntu 12.04 virtual machine (64-bit, using VirutalBox. Was also seeing the same problem on an older 32-bit Ubuntu VM running on VMWare), here's the log from make: https://gist.github.com/vky/6667170. |
|
@vky, looks like you have a different problem. You appear to be dying because of an out-of-memory situation, which happens when you haven't allocated enough ram to the VM or don't have enough swap I believe. Sadly rust requires a fair bit of memory right now, but hopefully that'll get under control soon. |
|
@alexcrichton You're right, gave it a try after giving the VM 3 gigs of ram instead of 2, and compilation worked. Didn't have this problem before and on a ram limited machine, so avoided giving the VM that much memory. Thanks. |
|
@tiffany352: is this still an issue? could you try narrowing down the test case a bit? |
|
I rebased this code to HEAD (in tiffany352/frp-rust#1), and it compiles now. Closing, but please reopen if my PR didn't actually fix the issue. |
Use `approx_ty_size` for `large_enum_variant` This builds upon rust-lang#9373 to use the approximate size of each variant for `large_enum_variant`. This allows us to lint in situations where an `enum` contains generics but is still guaranteed to have a large variant on an at-least basis, e.g. with `(T, [u8; 512])`. * I've changed the wording from "is ... bytes" to "contains at least" because * the size is now an approximate lower bound (e.g. `512` in the example above). The actual size is larger due to `T`, including due to `T`'s memory layout. * the discriminant is not taken into account in the message. This comes up with variants like `A(T)`, which are "is at least 0 bytes" otherwise, which may be misleading. * If the second-largest variant has no fields, there is a special case "carries no data" instead of "is at least 0 bytes". * A variant like `A(T)` is "at least 0 bytes", which is technically true, yet we don't distinguish between "indeterminate" and truly "ZST". * The generics-tests that were there before now lint while they didn't lint before. AFAICS this is correct. I guess the above is correct-ish. However, I use the `SubstsRef` that I got via `cx.tcx.type_of(item.def_id)` to solve for generics in the variants. Is this even applicable, since we start from an - [ ] `ItemKind`? changelog: none
Code can be found here: https://github.com/tiffany352/frp-rust
The text was updated successfully, but these errors were encountered: