Figuring out where a type is first referenced

[alexkirsz]

Hey folks,

rust-analyzer crashes often in our large Rust codebase at work, and it's often a pain for me to figure out exactly what code caused the crash.

Here's an example of such a crash from Zed's LSP logs:

stderr: thread 'Worker' panicked at crates/hir-ty/src/diagnostics/match_check/pat_analysis.rs:403:21:
stderr: internal error: entered unreachable code: Unexpected type for `Variant(EnumVariantContiguousIndex(0))` constructor: {error}
stderr: stack backtrace:
stderr: 0: _rust_begin_unwind
stderr: 1: core::panicking::panic_fmt
stderr: 2: <hir_ty::diagnostics::match_check::pat_analysis::MatchCheckCtx as ra_ap_rustc_pattern_analysis::PatCx>::ctor_sub_tys
stderr: 3: ra_ap_rustc_pattern_analysis::usefulness::compute_exhaustiveness_and_usefulness
stderr: 4: ra_ap_rustc_pattern_analysis::usefulness::compute_exhaustiveness_and_usefulness
stderr: 5: ra_ap_rustc_pattern_analysis::usefulness::compute_exhaustiveness_and_usefulness
stderr: 6: ra_ap_rustc_pattern_analysis::usefulness::compute_match_usefulness
stderr: 7: hir_ty::diagnostics::expr::BodyValidationDiagnostic::collect
stderr: 8: hir::DefWithBody::diagnostics
stderr: 9: hir::Module::diagnostics
stderr: 10: ide_diagnostics::diagnostics
stderr: 11: std::panicking::try
stderr: 12: salsa::Cancelled::catch
stderr: 13: ide::Analysis::assists_with_fixes
stderr: 14: rust_analyzer::handlers::request::handle_code_action
stderr: 15: std::panicking::try
stderr: 16: core::ops::function::FnOnce::call_once{{vtable.shim}}

I'm building rust-analyzer from source to try and attempt to fix or remedy these errors as I'm encountering them. From a Ty<Interner> and the HirDatabase, is there a way to figure out exactly where in the original source code this type was referenced? Or some other debug utility to add to rust-analyzer to get a better sense of where it's failing?

I'm currently using ty.display(db) to at least get an idea of what type caused the error, but I'm sometimes getting {unknown}.

[Veykril]

Not answering your question but #17534 should fix this. Mapping types back to syntax isnt really possible for us right now