LLVM assertion failure when compiling winapi with the latest nightly #35991
Assignees
Labels
P-high
High priority
regression-from-stable-to-nightly
Performance or correctness regression from stable to nightly.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
|
cc @eddyb, MIR related? |
|
Doubtful, especially if the previous nightly worked. cc @rust-lang/compiler |
|
I am seeing the same error when compiling |
|
@ruuda Did it start on that nightly, i.e. does it work with the previous nightly? |
|
@eddyb: The previous ci build is a bit older, it was |
|
If you use |
eddyb
added
I-nominated
T-compiler
|
For |
|
Minimal repro (even on non-windows platforms with struct Foo;
impl Drop for Foo {
fn drop(&mut self) {
panic!();
}
} |
|
|
|
Even smaller: fn bar() {
panic!();
} |
|
I am legitimately wondering how this could get past CI when we have |
|
@retep998 The bots don't have LLVM assertions enabled 😿. |
|
discussed briefly at the compiler meeting, leaving to eddyb to investigate before we can make any decision |
nrc
added
P-high
|
This only breaks with debuginfo enabled. STR: #![crate_type="rlib"]
pub fn unwind() {
panic!()
} |
|
@arielb1 Don't think the machine IR dump is relevant. @TimNN provided before and after IR on IRC. |
|
Has LLVM been updated in the meanwhile? Maybe this assertion is new. We might be adding methods to basic types which doesn't seem to be allowed (anymore?). |
|
@michaelwoerister Main difference AFAICT is that |
|
Well, for reference, there's #33358, which kind of looks relevant. But it's strange that it should become a problem now. |
|
Does !31 = !DICompositeType(tag: DW_TAG_structure_type, name: "TypeId", scope: !27, file: !8, size: 64, align: 64, elements: !32, identifier: "{struct core/1b4950c20447afca23a796609deae33a2e5e010df8c7a3efd1aeadd01355b84e/68dc}")
!64 = distinct !DISubprogram(name: "of<&str>", linkageName: "_ZN4core3any8{{impl}}8of<&str>E", scope: !31, file: !25, line: 381, type: !65, isLocal: false, isDefinition: true, scopeLine: 381, flags: DIFlagPrototyped, isOptimized: false, unit: !0, templateParams: !36, variables: !2)
!72 = !DIDerivedType(tag: DW_TAG_pointer_type, name: "*mut u8", baseType: !17, size: 32, align: 32)
!70 = distinct !DISubprogram(name: "is_null<u8>", linkageName: "_ZN4core3ptr8{{impl}}11is_null<u8>E", scope: !72, file: !71, line: 367, type: !73, isLocal: false, isDefinition: true, scopeLine: 367, flags: DIFlagPrototyped, isOptimized: false, unit: !0, templateParams: !76, variables: !2)
!146 = !DIDerivedType(tag: DW_TAG_pointer_type, name: "Box<&str>", baseType: !13, size: 32, align: 32)
!144 = distinct !DISubprogram(name: "new<&str>", linkageName: "_ZN5alloc5boxed8{{impl}}9new<&str>E", scope: !146, file: !145, line: 235, type: !147, isLocal: false, isDefinition: true, scopeLine: 235, flags: DIFlagPrototyped, isOptimized: false, unit: !0, templateParams: !36, variables: !2) |
|
The failure suggests #33358 shouldn't have worked. It didn't work, or regressed, in cross-crate cases. #![crate_type = "lib"]
pub struct Foo;
impl Foo {
pub fn foo() {}
}
pub fn bar() {
Foo::foo();
}
EDIT: Mystery elucidated: CodeView support in LLVM only allows "class" methods: if (const auto *Class = dyn_cast_or_null<DICompositeType>(Scope)) {
// If the scope is a DICompositeType, then this must be a method. Member
// function types take some special handling, and require access to the
// subprogram.The reason it hasn't been observed yet is two-fold: only inherent methods of types that are not structs, enums or tuples would trigger the problem, and cross-crate metadata regressed to |
bors
added a commit
that referenced
this issue
Aug 26, 2016
Do not emit "class method" debuginfo for types that are not DICompositeType. Fixes #35991 by restricting the "class method" debuginfo sugar from #33358 to structs and enums only. r? @michaelwoerister
chalcolith
added a commit
to chalcolith/ponyc
that referenced
this issue
Nov 19, 2017
…ods. Following [Rust's solution](rust-lang/rust#35991 (comment)), we make a dummy scope for primitive methods. This change also reorders some imports in codegen.h and gendebug.cc, as gendebug.h now depends on having PONY_LLVM defined.
This was referenced Nov 19, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When compiling a project that depends on
winapion the latest nightly, the compilation halts due to an llvm assertion failure whilewinapiis being built.Error message:
Toolchain/platform info
The text was updated successfully, but these errors were encountered: