Already completed forward declaration re-encountered in glfw-rs #14385
Labels
A-debuginfo
Area: Debugging information in compiled programs (DWARF, PDB, etc.)
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
Comments
Manishearth
changed the title
|
Here's a Travis build with the same error: https://travis-ci.org/Manishearth/servo/builds/25913272#L1935 |
|
Thanks for the report, @Manishearth! This seems to be a regression, possibly related to the internal representation of enums having slightly changed. I'll look into it next week. |
bors
added a commit
that referenced
this issue
May 29, 2014
So far the DWARF information for enums was different for regular enums, univariant enums, Option-like enums, etc. Regular enums were encoded as unions of structs, while the other variants were encoded as bare structs. With the changes in this PR all enums are encoded as unions so that debuggers can reconstruct if something originally was a struct, a univariant enum, or an Option-like enum. For the latter case, information about the *Null* variant is encoded into the union field name. This information can then be used by the debugger to print a `None` value actually as `None` instead of `Some(0x0)`. The changes in this PR should also fix the regression reported in #14385 and #14411, but I want to close these only after I have confirmation from the original reporters that the issues are actually fixed for them.
|
@Manishearth Can you take another look at this with a recent |
|
On it, pushed a new configuration to Travis here. It certainly won't compile completely since Servo is not yet updated to that version of Rust, but we can see if we're getting the same error. I'll investigate it more locally once Travis finishes. |
|
It seems to be trying to compile now. Compiler errors mean that it's working :) Mind if I leave this bug open for a while till we upgrade to that commit? I'll try to upgrade glfw beforehand and get atleast that crate compiling. Thanks. |
|
Sure, let's leave it open until we have a more thorough confirmation that the issue is actually gone. |
|
@michaelwoerister Still getting it: https://travis-ci.org/Manishearth/servo#L1945 (Tried it locally too, same error) |
|
Confirmed. It happens on a freshly compiled rustc. |
|
Might this be because we normally use stage2 in Servo and |
|
Could someone paste a gdb backtrace from a rust_fail breakpoint? |
|
@jdm, |
|
Could this be because instead of using the in-tree LLVM to build rustc (which takes too long for TravisCI to complete), we are using a system LLVM? Below paste contains details on which LLVM we are using: |
|
I'll look into this issue tomorrow. It's possible that the LLVM version has to do with it. In #14411 it also (?) only breaks with a custom LLVM version. The issue is related to the way LLVM collapses multiple IR metadata nodes into one, if they are the same. Maybe older LLVM versions do something different there (although 3.4 seems pretty new). I'll know more when I can reproduce the bug. |
|
@larsbergstrom Are you using the rustc version given in the listing above (commit 5effe33de4daae07115c485fd61dc22f0df48d3e)? Because this commit does not contain the fixes from PR #14486. If so, could you try again with a newer version (e.g. 0935beb)? |
|
Aha! Building with LLVM3.5 appears to get us past the problem (which was easy to do on Linux, given availability of 3.5 packages). If I can also handle it on OSX with LLVM3.4.1, I think we'll have a workaround for now. |
|
Glad to hear it. Mind though, that it might be possible that you were/are using a rustc version that does not yet contain the fix for the regression causing this issue. That should also resolve the issue. |
|
You're right - this did not work with 3.4.1, which was the best prebuilt LLVM I could get for OSX easily. I'm updating to the rustc version that you mentioned in the previous commit and will let you know if that works for us. Thanks! |
|
Great! If it still doesn't work then, I'll take another look and try to recreate your build environment. |
|
@michaelwoerister Unfortunately, your patches did not work against a prebuilt 3.4.1 LLVM - we still have this error. |
|
Well, in that case this will be the top-most item on my agenda tomorrow |
|
Indeed, I'm using a system LLVM. |
|
OK, I just was able to reproduce this. Using the in-tree LLVM version it works, but using an out-of-tree 3.4.1 LLVM on Mac OSX triggers the bug. |
|
OK, I found the culprit. Compiling things with a out-of-tree LLVM below version 3.5 would so faithfully fail because of the following snippet from return wrap(Builder->createStructType(
unwrapDI<DIDescriptor>(Scope),
Name,
unwrapDI<DIFile>(File),
LineNumber,
SizeInBits,
AlignInBits,
Flags,
unwrapDI<DIType>(DerivedFrom),
unwrapDI<DIArray>(Elements),
RunTimeLang,
unwrapDI<DIType>(VTableHolder)
#if LLVM_VERSION_MINOR >= 5
,UniqueId
#endif
));Yuck! |
|
😱 |
Exactly |
|
@michaelwoerister Your hard work is appreciated in Servo's relentless quest to reduce its build time requirements :-) |
|
This should be resolved by now. I've tested it against a current glfw-rs version and with LLVM 3.4.1 and it works fine. As soon as you are using a version of |
|
I checked a bit and it was resolved. Closing for now, though I'll redownload the snapshot and check again later. Thanks a bunch! :) |
|
@Manishearth You're welcome! |
|
Tried this with Rust@ |
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jun 5, 2023
Fix VS Code status message formatting error
flip1995
pushed a commit
to flip1995/rust
that referenced
this issue
Apr 3, 2025
Clarify example for unconditional_recursion changelog: none
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This seems similar to the already-fixed issue #11083
Note: I'm using a Rust snapshot that I generated on a different system (with the same DEFAULT_TARGET as mine)
cc @michaelwoerister
The text was updated successfully, but these errors were encountered: