Assosiated const str in match cause panic

[Dushistov]

rust-analyzer version: (eg. output of "rust-analyzer: Show RA Version" command, accessible in VSCode via Ctrl/⌘+Shift+P)

rust-analyzer 0.0.0 (11d45c8 2025-07-02)

rustc version: (eg. output of rustc -V)

rustc 1.88.0 (6b00bc388 2025-06-23)

editor or extension: (eg. VSCode, Vim, Emacs, etc. For VSCode users, specify your extension version; for users of other editors, provide the distribution if applicable)

GNU Emacs 30.1 (lsp-mode)

code snippet to reproduce:

trait Foo {
    const C: &str;
}

impl Foo for i32 {
    const C: &str = "i32";
}

impl Foo for i64 {
    const C: &str = "i64";
}

fn main() {
    let s = "i64";
    match s {
        i32::C => println!("this is i32"),
        i64::C => println!("this is i64"),
        _ => println!("unknown"),
    }
}

on my machine this cause panic:

thread 'Worker0' panicked at crates/hir-ty/src/mir.rs:183:21:
internal error: entered unreachable code: Overloaded deref on type str is not a projection
stack backtrace:
   0: __rustc::rust_begin_unwind
   1: core::panicking::panic_fmt
   2: hir_ty::mir::ProjectionElem<V,T>::projected_ty
   3: hir_ty::mir::borrowck::moved_out_of_ref::{{closure}}
   4: hir_ty::mir::borrowck::borrowck_query::{{closure}}
   5: hir_ty::mir::borrowck::borrowck_query
   6: salsa::function::execute::<impl salsa::function::IngredientImpl<C>>::execute
   7: salsa::function::fetch::<impl salsa::function::IngredientImpl<C>>::fetch_cold_with_retry
   8: salsa::function::fetch::<impl salsa::function::IngredientImpl<C>>::fetch
   9: std::thread::local::LocalKey<T>::with
  10: <DB as hir_ty::db::HirDatabase>::borrowck::borrowck_shim
  11: hir::DefWithBody::diagnostics
  12: hir::ModuleDef::diagnostics
  13: hir::Module::diagnostics
  14: ide_diagnostics::semantic_diagnostics
  15: ide_diagnostics::full_diagnostics
  16: salsa::cancelled::Cancelled::catch
  17: ide::Analysis::assists_with_fixes
  18: rust_analyzer::handlers::request::handle_code_action
  19: core::ops::function::FnOnce::call_once{{vtable.shim}}
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
query stacktrace:
   0: borrowck_shim(Id(1c1f0)) -> (R26, Durability::MEDIUM)
             at crates/hir-ty/src/db.rs:31

additional context:
   0: 
version: 0.0.0 (11d45c8813 2025-07-02)
request: textDocument/codeAction CodeActionParams {
    text_document: TextDocumentIdentifier {
        uri: Url {
            scheme: "file",
            cannot_be_a_base: false,
            username: "",
            password: None,
            host: None,
            port: None,
            path: "/Users/evgeniy/.emacs.d/rust-playground/at-2025-07-02-192510/src/main.rs",
            query: None,
            fragment: None,
        },
    },
    range: Range {
        start: Position {
            line: 22,
            character: 18,
        },
        end: Position {
            line: 22,
            character: 18,
        },
    },
    context: CodeActionContext {
        diagnostics: [],
        only: None,
        trigger_kind: None,
    },
    work_done_progress_params: WorkDoneProgressParams {
        work_done_token: None,
    },
    partial_result_params: PartialResultParams {
        partial_result_token: None,
    },
}

seems similar to #19500 , but backtrace is not exactly equal.

[ShoyuVanilla]

Leaving things I've learned while looking into this for further works - maybe me in this weekend or other people after some time 😄 -

Fun fact: we don't have this error for the following code:

trait Foo {
    const C: &'static str;
}

impl Foo for i32 {
    const C: &'static str = "i32";
}

impl Foo for i64 {
    const C: &'static str = "i64";
}

fn main() {
    let s = "i64";
    match s {
        i32::C => println!("this is i32"),
        i64::C => println!("this is i64"),
        _ => println!("unknown"),
    }
}

The only difference is that const C has explicit lifeitme &'static!

And here's why:

rust-analyzer/crates/hir-ty/src/infer/pat.rs

Lines 303 to 316 in 87940a9

	Pat::Path(path) => {
	let ty = self.infer_path(path, pat.into()).unwrap_or_else(|| self.err_ty());
	let ty_inserted_vars = self.insert_type_vars_shallow(ty.clone());
	match self.table.coerce(&expected, &ty_inserted_vars, CoerceNever::Yes) {
	Ok((adjustments, coerced_ty)) => {
	if !adjustments.is_empty() {
	self.result
	.pat_adjustments
	.entry(pat)
	.or_default()
	.extend(adjustments.into_iter().map(|adjust| adjust.target));
	}
	self.write_pat_ty(pat, coerced_ty);
	return self.pat_ty_after_adjustment(pat);

In the above lines, we pushes every coerce-resultant adjustment's target type into pat_adjustments and no matter what kind of adjust it is.

Actually, we are regarding all of them as deref adjustments as we can see here:

rust-analyzer/crates/hir-ty/src/mir/lower/pattern_matching.rs

Lines 114 to 132 in 87940a9

	fn pattern_match_inner(
	&mut self,
	mut current: BasicBlockId,
	mut current_else: Option<BasicBlockId>,
	mut cond_place: Place,
	pattern: PatId,
	mode: MatchingMode,
	) -> Result<(BasicBlockId, Option<BasicBlockId>)> {
	let cnt = self.infer.pat_adjustments.get(&pattern).map(|x| x.len()).unwrap_or_default();
	cond_place.projection = self.result.projection_store.intern(
	cond_place
	.projection
	.lookup(&self.result.projection_store)
	.iter()
	.cloned()
	.chain((0..cnt).map(|_| ProjectionElem::Deref))
	.collect::<Vec<_>>()
	.into(),
	);

But actually, what happens to the problematic code is that first, we are coercing s: &'static str into i32::C, which has type &'? str - we don't have precise lifetime lowering yet - in the match expression and this makes two adjustments: deref and borrow.

Yes, they are typical reborrow adjustments.

And they are both regarded as derefs as I wrote above, so our mir lowering logic is trying to "deref" &str two times to get the projected type and that makes the error Overloaded deref on type str is not a projection

rustc handles this more or less different from rust-analyzer.

It records deref adjustments only, but it has a dedicated type for them:

The only places it stores pattern adjustments are the following lines:

https://github.com/rust-lang/rust/blob/9e64506923cb0f18c2bb2b934edecff525774acc/compiler/rustc_hir_typeck/src/pat.rs#L509
https://github.com/rust-lang/rust/blob/9e64506923cb0f18c2bb2b934edecff525774acc/compiler/rustc_hir_typeck/src/pat.rs#L562

And the calculation of adjustment is not comming from the coerce result. It calculates how to "peel" references to fit the pattern into an expected type depending on pattern kinds and PeelKind, which is also calculated accordingly.

I think we should move rust-analyzer's pattern lowering logics closer to rustc's, or just fix current "everything is deref adjust" a bit into more accurate heuristics.
I'll look into this more when I have some time. Might this weekend or later.

[ShoyuVanilla]

And those PatAdjustment things are introduced in relatively recent PR: rust-lang/rust#138528, to implement implicit deref pattens. So I think that it would be okay to follow the rustc before that PR for now.