rust1: internal compiler error: in visit, at rust/typecheck/rust-hir-type-check-path.cc:144 #1132
Comments
|
Reduced case: pub trait Hasher {}Backtrace with debug info: Probably addressable by #1135 |
Yes. I have conducted a preliminary investigation, and it seems like this was due to Related: #658. |
|
Updated stack trace: The assertion here is part of a silly nullptr bug in the resolving of the segments i have been meaning to fix since last year lol |
philberty
added a commit
that referenced
this issue
Apr 25, 2022
When we resolve paths we don't have a _type_, in this senario there is a bug in our resolution of this generic function so this means the root_tyty is nullptr but the offset is non zero so we return nullptr. Addresses #1132
bors bot
added a commit
that referenced
this issue
Apr 26, 2022
1162: CI: catch malformed test cases r=philberty a=liushuyu - catch malformed test cases and use GitHub Actions' annotation feature to mark the failures 1167: Fix nullptr when resolving the root of a path expression r=philberty a=philberty When we resolve paths we don't have a _type_, in this scenario there is a bug in our resolution of this generic function so this means the root_tyty is nullptr but the offset is non zero so we return nullptr. Addresses #1132 This test case no longer ICE's but still fails. I have a fix in progress for this ```rust mod mem { extern "rust-intrinsic" { fn transmute<U, V>(_: U) -> V; } } pub trait Hasher { fn write(&mut self, bytes: &[u8]); fn write_u16(&mut self, i: u16) { self.write(&mem::transmute::<_, [u8; 2]>(i)) } } pub struct SipHasher; impl Hasher for SipHasher { #[inline] fn write(&mut self, msg: &[u8]) {} } ``` 1168: ast: resolve: Move ResolveItem into its own source file r=CohenArthur a=CohenArthur Since we need to add new functions to resolve visibilities, we might as well refactor this file before hand :) 1170: Implement macro expansion in `IfExpr`, `IfExprConseqElse`, `IfExprConseqIf`, `IfExprConseqIfLet`. r=CohenArthur a=antego Addresses #1141. Following up on #1161. This change adds support for the macros inside the `if` condition expressions. Things to note: 1. Judging by my research, the `IfExprConseqIfLet` isn't used. The parser treats the syntax `let var = if ...` as a `let` expression followed by `if` expression:  2. I didn't add the macro expansion to the `IfLetExpr...` family of expressions because I wasn't able to write a test case reproducing the missing macro expansion. I've tried the following code ```rust fn main() -> i32 { let mut res = 0; enum E { X(u8), Y(u8), Z(u8), } let v = E::Y(12); if let E::Y(n) = v { res = 1; } 0 } ``` which caused the compiler error ``` FAIL: rust/compile/macro43.rs (internal compiler error: in append_reference_for_def, at rust/resolve/rust-name-resolver.h:227) ``` Co-authored-by: liushuyu <liushuyu011@gmail.com> Co-authored-by: Philip Herron <philip.herron@embecosm.com> Co-authored-by: Arthur Cohen <arthur.cohen@embecosm.com> Co-authored-by: antego <antego@users.noreply.github.com>
|
Actually i will repoen to lets bors close out from #1190 |
bors bot
added a commit
that referenced
this issue
Apr 28, 2022
1190: Fix ICE in reachability class and refactor associated types code r=philberty a=philberty There are several fixes going on to solve these issues which overlap with one another so it seemed best to pack them within the same PR. The main issue for #1128 was that we did not resolve a trait when it was unused leading to us hitting the ICE in the privacy pass. Since the type check context was empty for the trait since it was not resolved. To fix this we needed to refactor the trait resolver to resolve the trait as part of iterating the crate. This resulted in some regressions in the testsuite so this is why we need the the other commits. Which required us to finally perform the refactor specified in #1105 to fix these. Fixes #1105 #1128 #1132 1192: Add an assertion to avoid peeking when the stack is empty r=philberty a=philberty This will ensure we get a proper ICE instead of memory corruption/segv. Addresses #1130 1193: Remove unused parameter caller from generating Call expressions r=philberty a=philberty Within const context the fncontext maybe empty which in turn results in a segv for generating const calls which will be evaluated by the const-expr code anyway. Addresses #1130 Co-authored-by: Philip Herron <philip.herron@embecosm.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I tried this code:
I expected to see this happen: explanation
Instead, this happened:
or as variation:
Meta
The text was updated successfully, but these errors were encountered: