ICE `in get_record, at rust/resolve/rust-name-resolution-context.h:370`
auto-reduced (treereduce-rust):
//@compile-flags: -frust-incomplete-and-experimental-compiler-do-not-use
struct Expr<const N: u32>;
trait Trait0 {
fn required(
_: Expr<
{
struct Type;
0
},
>,
);
}
original:
// Regression test for issue #89342 and for part of #119924.
//@ check-pass
struct Expr<const N: u32>;
trait Trait0 {
fn required(_: Expr<{
struct Type;
impl Type {
// This visibility qualifier used to get rejected.
pub fn perform() {}
}
0
}>);
}
trait Trait1 {}
impl Trait1 for ()
where
[(); {
struct Type;
impl Type {
// This visibility qualifier used to get rejected.
pub const STORE: Self = Self;
}
0
}]:
{}
fn main() {}
Version information:
c742973c23448e321fba4d9ff98a9092dc0df7ba
Possibly related line of code: https://github.com/Rust-GCC/gccrs/blob/c742973c23448e321fba4d9ff98a9092dc0df7ba/gcc/rust/resolve/rust-name-resolution-context.h#L364-L376
Command:
/home/matthias/vcs/github/gccrs/gccrs-build/gcc/crab1 -frust-incomplete-and-experimental-compiler-do-not-use
Program output
crab1: internal compiler error: in get_record, at rust/resolve/rust-name-resolution-context.h:370
0x300c7d8 internal_error(char const*, ...)
../../gcc/diagnostic-global-context.cc:534
0xc23693 fancy_abort(char const*, int, char const*)
../../gcc/diagnostics/context.cc:1640
0x90dc6f Rust::Resolver2_0::CanonicalPathCtx::get_record(unsigned int) const
../../gcc/rust/resolve/rust-name-resolution-context.h:370
0x90dc6f Rust::Resolver2_0::CanonicalPathCtx::get_path(unsigned int) const
../../gcc/rust/resolve/rust-name-resolution-context.h:364
0x90dc6f Rust::Resolver2_0::NameResolutionContext::to_canonical_path(unsigned int) const
../../gcc/rust/resolve/rust-name-resolution-context.h:549
0x90dc6f Rust::Resolver::TypeCheckItem::visit(Rust::HIR::StructStruct&)
../../gcc/rust/typecheck/rust-hir-type-check-item.cc:271
0x103f585 Rust::Resolver::TypeCheckItem::Resolve(Rust::HIR::Item&)
../../gcc/rust/typecheck/rust-hir-type-check-item.cc:57
0x107a72b ???
../../gcc/rust/typecheck/rust-hir-type-check-stmt.h:40
0x107ad43 Rust::Resolver::TypeCheckStmt::Resolve(Rust::HIR::Stmt&)
../../gcc/rust/typecheck/rust-hir-type-check-stmt.cc:34
0x106c504 Rust::Resolver::TypeCheckExpr::visit(Rust::HIR::BlockExpr&)
../../gcc/rust/typecheck/rust-hir-type-check-expr.cc:614
0x106ab44 Rust::Resolver::TypeCheckExpr::Resolve(Rust::HIR::Expr&)
../../gcc/rust/typecheck/rust-hir-type-check-expr.cc:50
0x1013316 Rust::TyTy::SubstitutionRef::get_mappings_from_generic_args(Rust::HIR::GenericArgs&, std::vector<Rust::TyTy::Region, std::allocator<Rust::TyTy::Region> > const&)
../../gcc/rust/typecheck/rust-tyty-subst.cc:788
0x10fe873 Rust::Resolver::SubstMapper::visit(Rust::TyTy::ADTType&)
../../gcc/rust/typecheck/rust-substitution-mapper.cc:112
0x10fdd27 Rust::Resolver::SubstMapper::Resolve(Rust::TyTy::BaseType*, unsigned long, Rust::HIR::GenericArgs*, std::vector<Rust::TyTy::Region, std::allocator<Rust::TyTy::Region> > const&)
../../gcc/rust/typecheck/rust-substitution-mapper.cc:47
0x10541ab Rust::Resolver::TypeCheckType::resolve_root_path(Rust::HIR::TypePath&, unsigned long*, bool*)
../../gcc/rust/typecheck/rust-hir-type-check-type.cc:461
0x1055cdf Rust::Resolver::TypeCheckType::visit(Rust::HIR::TypePath&)
../../gcc/rust/typecheck/rust-hir-type-check-type.cc:147
0x1052887 Rust::Resolver::TypeCheckType::Resolve(Rust::HIR::Type&)
../../gcc/rust/typecheck/rust-hir-type-check-type.cc:71
0x10538c7 Rust::Resolver::TypeCheckType::Resolve(Rust::HIR::Type&)
../../gcc/rust/typecheck/rust-hir-type-check-type.cc:67
0xfdfb0c Rust::Resolver::TraitItemReference::get_type_from_fn(Rust::HIR::TraitItemFunc&) const
../../gcc/rust/typecheck/rust-hir-type-check.cc:269
0x10351d2 Rust::Resolver::TraitItemReference::resolve_item(Rust::HIR::TraitItemFunc&)
../../gcc/rust/typecheck/rust-hir-trait-resolve.cc:400
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
If no one is working on this issue, please assign it to me.
Hi, whats the expected solution? I have added a check for inline structures and handled the exception such that it does not produce ICE. Now, one possible long term solution can be to make canonical path lookup explicit and optional instead of asserting on missing records. That would mean introducing an API such as get_canonical_path_opt() that returns an optional path for a NodeId, and then updating the callers to handle the “no canonical path exists” case explicitly.
Is this the expected solution or am I heading in wrong direction??
Theoretically, some items shouldn't have canonical paths. Currently, the compiler depends on some (?) items having canonical paths in order to produce the final GENERIC. Getting the compiler to handle not having canonical paths better would be great, and seems to be what you're currently doing, but tricky. Feel free to give it a shot.