Trying to type in a function with a proc macro applied causes a panic in rust analyzer #18840
Description
rust-analyzer version: 0.4.2244-standalone
rustc version: rustc 1.86.0-nightly (b3b368a18 2025-01-05)
editor or extension: vscodium rust-lang.rust-analyzer extension version 0.4.2244 via the openvsx registry
relevant settings: N/A
code snippet to reproduce (note: I doubt uefi's macro specifically is the problem, but I do not know enough about proc macros to test it myself. My best guess is that the modification of the signature or inserting into the body is confusing rust analyzer):
use uefi::Status;
#[uefi::entry]
fn efi_main() -> Status {
// try typing `let x = 1;` after this comment
loop {}
}[dependencies]
uefi = "0.33.0"
Panic info:
thread 'Worker' panicked at crates/hir-expand/src/fixup.rs:436:78:
called `Result::unwrap()` on an `Err` value: TryFromIntError(())
stack backtrace:
0: rust_begin_unwind
1: core::panicking::panic_fmt
2: core::result::unwrap_failed
3: hir_expand::fixup::reverse_fixups
4: <hir_expand::db::ExpandProcMacroQuery as ra_salsa::plumbing::QueryFunction>::execute
5: ra_salsa::Cycle::catch
6: ra_salsa::derived::slot::Slot<Q>::execute
7: ra_salsa::derived::slot::Slot<Q>::read
8: <ra_salsa::derived::DerivedStorage<Q> as ra_salsa::plumbing::QueryStorageOps<Q>>::fetch
9: <DB as hir_expand::db::ExpandDatabase>::expand_proc_macro
10: <hir_expand::db::ParseMacroExpansionQuery as ra_salsa::plumbing::QueryFunction>::execute
11: ra_salsa::Cycle::catch
12: ra_salsa::derived_lru::slot::Slot<Q,MP>::execute
13: <ra_salsa::derived_lru::DerivedStorage<Q,MP> as ra_salsa::plumbing::QueryStorageOps<Q>>::fetch
14: <DB as hir_expand::db::ExpandDatabase>::parse_macro_expansion
15: hir_expand::db::parse_or_expand
16: <hir_expand::db::AstIdMapQuery as ra_salsa::plumbing::QueryFunction>::execute
17: ra_salsa::Cycle::catch
18: ra_salsa::derived::slot::Slot<Q>::execute
19: ra_salsa::derived::slot::Slot<Q>::read
20: <ra_salsa::derived::DerivedStorage<Q> as ra_salsa::plumbing::QueryStorageOps<Q>>::fetch
21: <DB as hir_expand::db::ExpandDatabase>::ast_id_map
22: hir_def::item_tree::ItemTree::file_item_tree_with_source_map_query
23: ra_salsa::Cycle::catch
24: ra_salsa::derived::slot::Slot<Q>::execute
25: ra_salsa::derived::slot::Slot<Q>::read
26: <ra_salsa::derived::DerivedStorage<Q> as ra_salsa::plumbing::QueryStorageOps<Q>>::fetch
27: <DB as hir_def::db::DefDatabase>::file_item_tree_with_source_map
28: ra_salsa::Cycle::catch
29: ra_salsa::derived::slot::Slot<Q>::execute
30: ra_salsa::derived::slot::Slot<Q>::read
31: <ra_salsa::derived::DerivedStorage<Q> as ra_salsa::plumbing::QueryStorageOps<Q>>::fetch
32: <DB as hir_def::db::DefDatabase>::file_item_tree
33: hir_def::nameres::collector::DefCollector::collect_macro_expansion
34: hir_def::nameres::collector::collect_defs
35: hir_def::nameres::DefMap::crate_def_map_query
36: ra_salsa::Cycle::catch
37: ra_salsa::derived::slot::Slot<Q>::execute
38: ra_salsa::derived::slot::Slot<Q>::read
39: <ra_salsa::derived::DerivedStorage<Q> as ra_salsa::plumbing::QueryStorageOps<Q>>::fetch
40: <DB as hir_def::db::DefDatabase>::crate_def_map
41: hir::semantics::source_to_def::SourceToDefCtx::file_to_def
42: hir::semantics::SemanticsImpl::file_to_module_defs
43: hir::semantics::SemanticsImpl::attach_first_edition
44: ide::syntax_highlighting::highlight
45: ra_salsa::Cancelled::catch
46: rust_analyzer::handlers::request::handle_semantic_tokens_full_delta
47: core::ops::function::FnOnce::call_once{{vtable.shim}}
almost certainly caused by commit ceba289 (cc #18327) which completely reworks the section of the code that panics. Switching to version 0.4.2238 which is before that commit does not reproduce this issue.